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PRIORITY CLAIM 



This application is a continuation in part of U.S. patent application serial number 
10/422,632 entitled “Graphical Input Display In An Insurance Processing System” by 
5 Stefan Wahlbin filed on April 24, 2003, which is incorporated herein by reference in its 
entirety. 

BACKGROUND OF THE INVENTION 

10 1. Field of the Invention 

Embodiments presented herein generally relate to insurance claim processing. 
More particularly, embodiments relate to a system and method for providing input to an 
insurance claim processing system using a graphical user interface. 

15 

2. Description of the Related Art 

Insurance companies have been processing and settling claims associated with 
bodily injury for a long time. The task of evaluating, analyzing or estimating the amount 

20 of damage associated with one or more types of bodily injuries, especially trauma- 

induced bodily injuries, can be very complex. Complexity in the evaluation process often 
arises out of the fact that concurrent expertise in legal, medical and insurance fields is 
often required to arrive at a particular decision involving a bodily injury claim. 

25 Several factors can affect the estimated amount of the claim associated with a 

bodily injury. Every accident is different and every injury is unique. Arriving at a 
customized evaluation of a bodily injury claim, which is unique for a specific accident, 
injury, etc. is desirable. Applying across-the-board standards may tend to result in an 
inequitable solution for one or more parties involved. External environmental factors, 

30 such as the experience level of a claims adjuster, record of accomplishment of the legal 
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professionals, post-injury quality of life for the injured party, etc., all may affect the 
valuation of a claim. 

During the past several years, many insurance companies have been using 
5 computer-based and knowledge-based claim-processing systems to process, evaluate, 
analyze and estimate thousands of claims in what is believed to be a fair and consistent 
manner. A knowledge-based claim-processing system may include an expert system 
which utilizes and builds a knowledge base to assist the user in decision making. Such a 
system may allow the insurance companies to define new business rules and/or use 
10 previously defined rules, in real-time. The business rules are generally written by 
industry experts to evaluate legal, medical, insurance conditions before arriving at a 
valuation of a claim. 

An insurance claim processing system may determine valuation of a claim by first 
15 determining the severity of the claim. Several measures of severity of a claim may 
include, but are not limited to trauma severity values and bodily impairment values. 

Claim severity may be associated with a monetary amount. In some instances, different 
zones or geographic regions (e.g., different states within the United States) may have 
different monetary values associated with claims of the same severity (e.g., claims having 
20 the same bodily impairment, trauma severity values, etc.). 
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SUMMARY OF THE INVENTION 



Embodiments presented herein generally relate to insurance claim processing. 
More specifically embodiments relate to methods of providing input to an insurance 
5 claim processing system via a graphical interface. 

In some embodiments, input may be received in a graphical display for an 
insurance claim processing system. In some embodiments, the graphical display may 
include a human body representation. A body part in the human body representation may 
10 be selected, and, when a body part is selected, input selection information corresponding 
to the selected body part may be displayed. An input selection may be selected from the 
displayed input selection information. The input selection may include a selection of a 
body part/subpart and injuries (e.g., injury codes) for the body part. Other information 
(e.g., treatment information) may also be entered. In some embodiments, an input 
15 selection may include an injury type and an injured area. In response to receiving an 
input selection, information may be displayed in the graphical display corresponding to 
the received input selection. 

In various embodiments, a human body representation may include a 
20 representation of a human skeletal system, a representation of human musculature, a 

representation of a human nervous system, and/or a representation of a human circulatory 
system. The representations may include one or more layers of anatomical systems and 
organs associated with anatomical systems. In various embodiments, a listing of 
available human body representations may be displayed with indicators to indicate which 
25 human body representation is currently being displayed. In some embodiments, 
indicators may also be displayed to indicate which representations have had input 
selections received from a user. 

In some embodiments, a menu may be displayed relative to a selected body part 
30 to display body parts and subparts corresponding to a selected region. In some 
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embodiments, selecting a body part from the menu may result in injuries the body part 
may experience being listed relative to the selected body part. For example, a drop down 
or popup menu of injuries may be displayed relative to a selected body part. Other 
information may also be displayed. For example, if an injury is selected from the list, a 
5 listing of available treatments may be displayed. In some embodiments, injuries entered 
for the insurance claim may have corresponding indicators to indicate whether the 
injuries should be considered with the insurance claim. For example, if an injury has not 
been confirmed, the injury may be entered (but not checked) and, when the injury is 
confirmed, a check box indicator next to the injury may be checked. 

10 

In some embodiments, an input field may be provided with the human body 
representation to receive input from a user. For example, a user may type input into the 
input field related to one or more body parts. In some embodiments, input may be 
entered by selecting options (e.g., subparts, injuries, and treatments) from a menu on the 

15 graphical display. In some embodiments, one or more body parts may be highlighted in 
the graphical display in response to input received (e.g., a user may select a body part by 
clicking on it with a mouse and entering information in the input field or selecting an 
option from a drop down menu). 

20 Additional embodiments may include a computer memory medium or computer 

system configured to implement methods as described above. Additional embodiments 
may include implementing methods as described above on two or more computers 
connected by a network. For example, the network may include the Internet. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



Other objects and advantages of the invention will become apparent upon reading 
the following detailed description and upon reference to the accompanying drawings in 
5 which: 

Fig. la is a block diagram illustrating the architecture of one embodiment of an 
insurance claims processing system; 

Fig. lb illustrates one embodiment of a networked insurance claim processing 

10 system; 

Fig. lc is a block diagram illustrating the architecture of one embodiment of an 
insurance claims processing system; 

Fig. 2 illustrates a structure for an insurance claims processing help database that 
may be used for context sensitive help and for searching for terms according to one 

1 5 embodiment of an insurance claim processing system; 

Fig. 3 illustrates a table including document header information according to one 
embodiment of an insurance claim processing system; 

Fig. 4 illustrates a table including document text information according to one 
embodiment of an insurance claim processing system; 

20 Fig. 5 illustrates an index table including terms and codes and cross-references to 

other tables according to one embodiment of an insurance claim processing system; 

Fig. 6a is a flow diagrams illustrating a method for generating the various tables 
in an insurance claims processing help database according to one embodiment of an 
insurance claim processing system; 

25 Figs. 6b through 6h are flow diagrams illustrating a mechanism for generating 

relevance values for occurrences in an insurance claims processing help database 
according to one embodiment of an insurance claims processing system; 

Figs. 7a-7c are flow diagrams illustrating a mechanism for providing context- 
sensitive help according to one embodiment of an insurance claim processing system; 
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Fig. 8 illustrates a display screen showing multiple panes, wherein two of the 
panes comprise context sensitive help information, according to one embodiment of an 
insurance claim processing system; 

Fig. 9 is a flow diagram illustrating a mechanism for searching for insurance 
5 claims processing terms according to one embodiment of an insurance claim processing 
system; 

Fig. 10 illustrates a display screen showing multiple panes, wherein two of the 
panes comprise search results information, according to one embodiment of an insurance 
claim processing system; 

10 Fig. 10a illustrates an alternate embodiment of a display screen showing multiple 

panes, wherein two or more of the panes comprise search results information. 

Fig. 1 1 shows the display screen of Fig. 10, with one of the search results panes 
hidden to provide more display area for claims processing information, according to one 
embodiment of an insurance claim processing system; 

15 Fig. Id is a network diagram of an illustrative distributed computing environment 

which is suitable for implementing various embodiments; 

Fig. 2aA is an illustration of an insurance claims processing server computer 
architecture according to one embodiment; 

Fig. 2bA is an illustration of an insurance claims processing client computer 

20 architecture according to one embodiment; 

Fig. 3aA is an illustration of an insurance claims processing server software 
architecture for a single client according to one embodiment; 

Fig. 3bA is an illustration of an insurance claims processing server software 
architecture for multiple clients according to one embodiment; 

25 Fig. 4A is an illustration of adapter software between a rules engine and a web 

server according to one embodiment; 

Fig. 5A illustrates the transmission of data between a web server and a web 
browser according to one embodiment; 



Atty. Dkt. No.: 5053-63200 



Page 6 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C 




Fig. 6A illustrates an example of a browser-based user interface for the insurance 
claims processing system according to one embodiment; 

Fig. 7A is a flowchart illustrating a method of developing a web-based insurance 
claims processing system according to one embodiment; 

5 Fig. 8A is a flowchart illustrating a method of hosting a web-based insurance 

claims processing server with various pricing models according to one embodiment; 

Fig. 9A is a flowchart illustrating a method of using a reset button provided by a 
web-based interface to a web-based insurance claims processing server according to one 
embodiment; 

10 Fig. 2B illustrates a flow chart to generate a table of contents for processing an 

insurance claim according to one embodiment; 

Fig. 3B illustrates detail of step 150B in Fig. 2B; 

Fig. 4B is a flowchart illustrating the use of a table of contents for processing an 
insurance claim according to one embodiment; 

15 Fig. 5B illustrates a screen shot of a table of contents display screen according to 

a first embodiment; 

Fig. 5Ba illustrates a screen shot of a table of contents display screen according to 
a second embodiment; 

Fig. 6B illustrates exemplary properties and methods associated with a display 
20 screen object according to a first embodiment; 

Fig. 6Ba illustrates exemplary properties and methods associated with a display 
screen object according to a second embodiment 

Fig. 2C is a flow chart illustrating the process of identifying critical factors 
affecting the fair estimate value, included in an insurance claim consultation report, 

25 according to one embodiment; 

Fig. 3C illustrates a table for storing injury codes, treatment codes and 
contributing factor values according to one embodiment; 

Fig. 2D illustrates a flow chart to transform formula data to formulas for assessing 
bodily injury damages claims according to one embodiment; 
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Fig. 3D illustrates data elements of a formula table according to one embodiment; 

Fig. 2E illustrates a flow chart to transform rules data to rules for assessing bodily 
injury damages claims according to one embodiment; 

Fig. 3aE illustrates data elements of a rules data table according to one 
5 embodiment; 

Fig. 3bE illustrates data elements of a template table according to one 
embodiment; 

Fig. 3cE illustrates data elements of a line text table according to one 
embodiment; 

10 Fig. 4E illustrates a block diagram of the transformation of rules data to rules for 

assessing bodily injury damages according to one embodiment; 

Fig. 2F is a flowchart illustrating a method of generating messages associated 
with processing an insurance claim according to one embodiment; 

Fig. 3F is a flowchart illustrating a method of using a messages table associated 
15 with processing an insurance claim according to one embodiment; 

Fig. 4F is an exemplary diagram of a messages table in a database according to 
one embodiment; 

Fig. 12 illustrates an embodiment of a block diagram of a rule editor and 
associated database tables; 

20 Fig. 13 depicts an exemplary embodiment of a rule editor display screen showing 

a template tab; 

Fig. 14 depicts an exemplary embodiment of a rule editor display screen showing 
a variable tab; 

Fig. 15 depicts an exemplary embodiment of a rule editor display screen showing 
25 a parameter tab; 

Fig. 16 depicts an exemplary embodiment of a method of providing a graphical 
interface of an insurance claim processing business rule; 

Fig. 17 depicts an exemplary embodiment of a method of providing an interactive 
graphical interface of an insurance claim processing business rule; 
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Fig. 1 8 depicts an exemplary embodiment of a rule editor display screen showing 
an SQL tab; 

Fig. 19 depicts an exemplary embodiment of a method of generating new 
insurance claim processing business rule using a rule editor; 

5 Fig. 20 depicts an exemplary embodiment of a rule editor display screen showing 

a tables tab; 

Fig. 21 depicts a first exemplary embodiment of a method of providing a display 
of business rule components that are related using a rule editor; 

Fig. 22 depicts a second exemplary embodiment of a method of providing a 
10 display of business rule components that are related using a rule editor; 

Fig. 23 depicts an exemplary embodiment of a method of tracking modifications 
to a business rule in a rule editor; 

Fig. 24 depicts an exemplary embodiment of a rule editor display screen showing 
an audit tab; 

15 Fig. 25 depicts an exemplary embodiment of a rule editor display screen showing 

a text tab; 

Fig. 26 depicts an exemplary embodiment of a method of providing a human 
language translation of at least one business rule component in a rule editor; 

Fig. 27 depicts an embodiment of a graphical display in an insurance transaction 
20 processing program including a first human body representation; 

Fig. 28 depicts an embodiment of a graphical display in an insurance transaction 
processing program including a second human body representation; 

Fig. 29 depicts an embodiment of a graphical display in an insurance transaction 
processing program including a third human body representation; 

25 Fig. 30 depicts an embodiment of a graphical display in an insurance transaction 

processing program including a fourth human body representation; 

Fig. 31 depicts an embodiment of a graphical display in an insurance transaction 
processing program including a representation of a portion of the human body; 
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FIG. 32 depicts an embodiment of a graphical display in an insurance transaction 
processing program for input and display of information, according to an embodiment; 

FIG. 33 depicts an embodiment of a graphical display in an insurance transaction 
processing program including a representation of a spine; 

5 FIG. 34 depicts an embodiment of a graphical display in an insurance transaction 

processing program with multiple injuries indicated; 

FIG. 35 depicts an embodiment of a graphical display in an insurance transaction 
processing program for inputting and displaying information about a spine; 

FIG. 36 depicts an embodiment of a graphical display in an insurance transaction 
10 processing program for inputting and displaying information relative to human skin; 

FIG. 37 depicts an embodiment of a graphical display in an insurance transaction 
processing program for inputting and displaying information relative to an abdomen 
region; 

FIG. 38 depicts an embodiment of a graphical display in an insurance transaction 
15 processing program for inputting and displaying information relative to a muscular 
representation; 

FIG. 39 depicts a flowchart of an embodiment for entering information relative to 
a selected body part; and 

FIG. 40 depicts a flowchart of an embodiment for highlighting a selected body 
20 part and receiving related input. 

While the invention is susceptible to various modifications and alternative forms, 
specific embodiments thereof are shown by way of example in the drawings and will 
herein be described in detail. It should be understood, however, that the drawings and 
25 detailed description thereto are not intended to limit the invention to the particular form 
disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and 
alternatives falling within the spirit and scope of the present invention as defined by the 
appended claims. 

30 
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DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS 



U.S. Patent Application Serial No. 09/603,307 titled “SYSTEM AND METHOD 
FOR PROCESSING INSURANCE CLAIMS USING A TABLE OF CONTENTS” filed 
5 on June 23, 2000 whose inventors are Allen B. Childress and Gregory Jones is hereby 
incorporated by reference in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/603,129 titled “SYSTEM AND METHOD 
FOR IDENTIFYING CRITICAL FACTORS AFFECTING AN ESTIMATED VALUE 
INCLUDED IN AN INSURANCE CLAIM CONSULTATION REPORT” filed on June 
10 23, 2000 whose inventor is Gregory Jones is hereby incorporated by reference in its 

entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/603,662 titled “RELEVANCE 
CALCULATION FOR A REFERENCE SYSTEM IN AN INSURANCE CLAIMS 
PROCESSING SYSTEM” filed on June 23, 2000 whose inventor is Allen B. Childress is 
15 hereby incorporated by reference in its entirety as though fully and completely set forth 
herein. 

U.S. Patent Application Serial No. 09/603,308 titled “SYSTEM AND METHOD 
FOR EXTERNALIZATION OF FORMULAS FOR ASSESSING DAMAGES” filed on 
June 23, 2000 whose inventors are Brian Wolfe and Allison W. Spann is hereby 
20 incorporated by reference in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/603,144 titled “SYSTEM AND METHOD 
FOR EXTERNALIZATION OF RULES FOR ASSESSING DAMAGES” filed on June 
23, 2000 whose inventors are Gregory Jones and Allison W. Spann is hereby 
incorporated by reference in its entirety as though fully and completely set forth herein. 

25 U.S. Patent Application Serial No. 09/602,687 titled “WEB-ENABLED SYSTEM 

AND METHOD FOR ASSESSING DAMAGES” filed on June 23, 2000 whose inventor 
is Scott Lorenz is hereby incorporated by reference in its entirety as though fully and 
completely set forth herein. 

U.S. Patent Application Serial No. 09/603,302 titled “DYNAMIC HELP 
30 SYSTEM FOR AN INSURANCE CLAIMS PROCESSING SYSTEM” filed on June 23, 
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2000 whose inventor is Allen B. Childress is hereby incorporated by reference in its 
entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/602,691 titled “GRAPHICAL USER 
INTERFACE WITH A HIDE/SHOW FEATURE FOR A REFERENCE SYSTEM IN 
5 AN INSURANCE CLAIMS PROCESSING SYSTEM” filed on June 23, 2000 whose 
inventor is Allen B. Childress is hereby incorporated by reference in its entirety as though 
fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/603,130 titled “RESET BUTTON FOR 
WEB-ENABLED SYSTEM AND METHOD FOR ASSESSING DAMAGES” filed on 
10 June 23, 2000 whose inventor is Scott Lorenz is hereby incorporated by reference in its 
entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/603,303 titled “INTERNET-ENABLED 
SYSTEM AND METHOD FOR ASSESSING DAMAGES” filed on June 23, 2000 
whose inventor is Scott Lorenz is hereby incorporated by reference in its entirety as 
15 though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/603,304 titled “PRICING MODELS FOR 
WEB-ENABLED SYSTEM AND METHOD FOR ASSESSING DAMAGES” filed on 
June 23, 2000 whose inventor is Scott Lorenz is hereby incorporated by reference in its 
entirety as though fully and completely set forth herein. 

20 U.S. Patent Application Serial No. 09/603,306 titled “SYSTEM AND METHOD 

FOR DISPLAYING MESSAGES USING A MESSAGES TABLE” filed on June 23, 
2000 whose inventor is Brian Wolfe is hereby incorporated by reference in its entirety as 
though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/238,025 titled “COMPUTERIZED 
25 METHOD AND SYSTEM FOR ESTIMATING PREMISES LIABILITY FOR AN 
ACCIDENT” filed on September 9, 2002 whose inventors are Stefan Wahlbin and Gilda 
Reynolds is hereby incorporated by reference in its entirety as though fully and 
completely set forth herein. 
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U.S. Patent Application Serial No. 10/238,029 titled “COMPUTERIZED 
METHOD AND SYSTEM FOR DETERMINING CLAIMANT STATUS IN 
PREMISES LIABILITY FOR AN ACCIDENT” filed on September 9, 2002 whose 
inventors are Stefan Wahlbin and Gilda Reynolds is hereby incorporated by reference in 
5 its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/238,019 titled “COMPUTERIZED 
METHOD AND SYSTEM FOR DETERMINING BREACH OF DUTY IN PREMISES 
LIABILITY FOR AN ACCIDENT” filed on September 9, 2002 whose inventors are 
Stefan Wahlbin and Gilda Reynolds is hereby incorporated by reference in its entirety as 
10 though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/237,547 titled “COMPUTERIZED 

METHOD AND SYSTEM FOR DETERMINING CAUSATION IN PREMISES 
LIABILITY FOR AN ACCIDENT” filed on September 9, 2002 whose inventors are 
Stefan Wahlbin and Gilda Reynolds is hereby incorporated by reference in its entirety as 
15 though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/238,981 titled “COMPUTERIZED 

METHOD AND SYSTEM FOR DETERMINING THE CONTRIBUTION OF 
DEFENSES TO PREMISES LIABILITY FOR AN ACCIDENT” filed on September 9, 
2002 whose inventors are Stefan Wahlbin and Gilda Reynolds is hereby incorporated by 
20 reference in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/969,516 titled “COMPUTERIZED 

METHOD AND SYSTEM OF LIABILITY ASSESSMENT FOR AN ACCIDENT” filed 
on October 2, 2001 whose inventors are Stefan Wahlbin and Tim Johnston is hereby 
incorporated by reference in its entirety as though fully and completely set forth herein. 

25 U.S. Patent Application Serial No. 09/969,017 titled “COMPUTERIZED 

METHOD AND SYSTEM OF DETERMINING RIGHT OF WAY AND LIABILITY 
FOR AN ACCIDENT” filed on October 2, 2001 whose inventors are Stefan Wahlbin and 
Tim Johnston is hereby incorporated by reference in its entirety as though fully and 
completely set forth herein. 
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U.S. Patent Application Serial No. 09/969,545 titled “COMPUTERIZED 

METHOD AND SYSTEM OF ASSESSING AND ADJUSTING LIABILITY FOR AN 
ACCIDENT” filed on October 2, 2001 whose inventors are Stefan Wahlbin and Tim 
Johnston is hereby incorporated by reference in its entirety as though fully and 
5 completely set forth herein. 

U.S. Patent Application Serial No. 09/969,546 titled “COMPUTERIZED 

METHOD AND SYSTEM OF ESTIMATING LIABILITY AND RANGE OF 
LIABILITY FOR AN ACCIDENT” filed on October 2, 2001 whose inventors are Stefan 
Wahlbin and Tim Johnston is hereby incorporated by reference in its entirety as though 

10 fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/969,015 titled “COMPUTERIZED 

METHOD AND SYSTEM OF DETERMINING RIGHT OF WAY IN AN ACCIDENT” 

filed on October 2, 2001 whose inventors are Stefan Wahlbin and Tim Johnston is hereby 
incorporated by reference in its entirety as though fully and completely set forth herein. 

15 U.S. Patent Application Serial No. 09/969,022 titled “COMPUTERIZED 

METHOD AND SYSTEM OF ASSESSING LIABILITY FOR AN ACCIDENT USING 
IMPACT GROUPS” filed on October 2, 2001 whose inventors are Stefan Wahlbin and 
Tim Johnston is hereby incorporated by reference in its entirety as though fully and 
completely set forth herein. 

20 U.S. Patent Application Serial No. 09/969,016 titled “COMPUTERIZED 

METHOD AND SYSTEM OF ASSIGNING AN ABSOLUTE LIABILITY VALUE 
FOR AN ACCIDENT” filed on October 2, 2001 whose inventors are Stefan Wahlbin and 
Tim Johnston is hereby incorporated by reference in its entirety as though fully and 
completely set forth herein. 

25 U.S. Patent Application Serial No. 09/969,536 titled “COMPUTERIZED 

METHOD AND SYSTEM OF LIABILITY ASSESSMENT FOR AN ACCIDENT 
USING ENVIRONMENTAL, VEHICLE, AND DRIVER CONDITIONS AND 
DRIVER ACTIONS” filed on October 2, 2001 whose inventors are Stefan Wahlbin and 
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Tim Johnston is hereby incorporated by reference in its entirety as though fully and 
completely set forth herein. 

U.S. Patent Application Serial No. 09/969,534 titled “COMPUTERIZED 

METHOD AND SYSTEM FOR ACCUMULATING LIABILITY ESTIMATES” filed 
5 on October 2, 2001 whose inventors are Stefan Wahlbin and Tim Johnston is hereby 
incorporated by reference in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/969,018 titled “COMPUTERIZED 

METHOD AND SYSTEM FOR ADJUSTING LIABILITY ESTIMATES IN AN 
ACCIDENT LIABILITY ASSESSMENT PROGRAM” filed on October 2, 2001 whose 
10 inventors are Stefan Wahlbin and Tim Johnston is hereby incorporated by reference in its 
entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/969,019 titled “COMPUTERIZED 

METHOD AND SYSTEM FOR ADJUSTING LIABILITY ESTIMATION FACTORS 

IN AN ACCIDENT LIABILITY ASSESSMENT PROGRAM” filed on October 2, 2001 
15 whose inventors are Stefan Wahlbin and Tim Johnston is hereby incorporated by 
reference in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/970,161 titled “COMPUTERIZED 

METHOD AND SYSTEM FOR PROVIDING CLAIMS DATA TO AN ACCIDENT 

LIABILITY ASSESSMENT PROGRAM” filed on October 2, 2001 whose inventors are 
20 Stefan Wahlbin and Tim Johnston is hereby incorporated by reference in its entirety as 
though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/969,021 titled “COMPUTERIZED 

METHOD AND SYSTEM OF DISPLAYING AN ACCIDENT TYPE” filed on October 
2, 2001 whose inventors are Stefan Wahlbin and Tim Johnston is hereby incorporated by 
25 reference in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/969,027 titled “COMPUTERIZED 

METHOD AND SYSTEM OF DISPLAYING A ROADWAY CONFIGURATION 
RELATING TO AN ACCIDENT” filed on October 2, 2001 whose inventors are Stefan 
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Wahlbin and Tim Johnston is hereby incorporated by reference in its entirety as though 
fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/969,039 titled “COMPUTERIZED 
METHOD AND SYSTEM OF DISPLAYING AN IMPACT POINT RELATING TO 
5 AN ACCIDENT” filed on October 2, 2001 whose inventors are Stefan Wahlbin and Tim 
Johnston is hereby incorporated by reference in its entirety as though fully and 
completely set forth herein. 

U.S. Patent Application Serial No. 09/969,020 titled “COMPUTERIZED 

METHOD AND SYSTEM OF DETERMINING INCONSISTENCIES IN WITNESS 
10 STATEMENTS RELATING TO AN ACCIDENT” filed on October 2, 2001 whose 
inventors are Stefan Wahlbin and Tim Johnston is hereby incorporated by reference in its 
entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/969,146 titled “COMPUTERIZED 

METHOD AND SYSTEM OF IDENTIFYING A CREDIBLE WITNESS STATEMENT 
15 RELATING TO AN ACCIDENT” filed on October 2, 2001 whose inventors are Stefan 
Wahlbin and Tim Johnston is hereby incorporated by reference in its entirety as though 
fully and completely set forth herein. 

U.S. Patent Application Serial No. 09/969,024 titled “COMPUTERIZED 

METHOD AND SYSTEM OF DETERMINING A CREDIBLE REAL SET OF 

20 CHARACTERISTICS FOR AN ACCIDENT” filed on October 2, 2001 whose inventors 
are Stefan Wahlbin and Tim Johnston is hereby incorporated by reference in its entirety 
as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/285,292 titled “GRAPHICAL DISPLAY 
OF BUSINESS RULES” filed on October 31, 2002 whose inventors are Allen B. 
25 Childress and Allison W. Spann is hereby incorporated by reference in its entirety as 
though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/285,289 titled “METHOD OF 
MODIFYING A BUSINESS RULE” filed on October 31, 2002 whose inventors are 



Atty. Dkt. No.: 5053-63200 



Page 16 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C 




Allen B. Childress and Allison W. Spann is hereby incorporated by reference in its 
entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/285,339 titled “METHOD OF 

MODIFYING A BUSINESS RULE WHILE TRACKING THE MODIFICATIONS” 
5 filed on October 31, 2002 whose inventors are Allen B. Childress and Allison W. Spann 
is hereby incorporated by reference in its entirety as though fully and completely set forth 
herein. 

U.S. Patent Application Serial No. 10/285,375 titled “METHOD OF FORMING 
A BUSINESS RULE” filed on October 31, 2002 whose inventors are Allen B. Childress 
10 and Allison W. Spann is hereby incorporated by reference in its entirety as though fully 
and completely set forth herein. 

U.S. Patent Application Serial No. 10/285,338 titled “METHOD OF 

GENERATING A GRAPHICAL DISPLAY OF A BUSINESS RULE WITH A 
TRANSLATION” filed on October 31, 2002 whose inventors are Allen B. Childress and 
15 Allison W. Spann is hereby incorporated by reference in its entirety as though fully and 
completely set forth herein. 

U.S. Patent Application Serial No. 10/285,293 titled “METHOD OF 

GENERATING A GRAPHICAL DISPLAY OF A BUSINESS RULE AND 

ASSOCIATED BUSINESS RULE ELEMENTS” filed on October 31, 2002 whose 
20 inventors are Allen B. Childress and Allison W. Spann is hereby incorporated by reference 
in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/306,864 titled “COMPUTERIZED 
METHOD AND SYSTEM FOR ESTIMATING LIABILITY FOR AN ACCIDENT 
FROM AN INVESTIGATION OF THE ACCIDENT” filed on November 27, 2002 
25 whose inventors are Stefan Wahlbin, Kathleen E. Rourke, and Kimberly Wiesman is 
hereby incorporated by reference in its entirety as though fully and completely set forth 
herein. 

U.S. Patent Application Serial No. 10/306,873 titled “COMPUTERIZED 
METHOD AND SYSTEM FOR ESTIMATING LIABILITY USING DYNAMIC 
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GENERATION OF QUESTIONS” filed on November 27, 2002 whose inventors are 
Stefan Wahlbin, Kathleen E. Rourke, and Kimberly Wiesman is hereby incorporated by 
reference in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/306,909 titled “COMPUTERIZED 
5 METHOD AND SYSTEM FOR ESTIMATING AN EFFECT ON LIABILITY OF THE 
SPEED OF VEHICLES IN AN ACCIDENT AND TIME AND DISTANCE 
TRAVELED BY THE VEHICLES” filed on November 27, 2002 whose inventors are 
Stefan Wahlbin, Kathleen E. Rourke, and Kimberly Wiesman is hereby incorporated by 
reference in its entirety as though fully and completely set forth herein. 

10 U.S. Patent Application Serial No. 10/306,623 titled “COMPUTERIZED 

METHOD AND SYSTEM FOR ESTIMATING AN EFFECT ON LIABILITY USING 
A COMPARISON OF THE ACTUAL SPEED OF A VEHICLE IN AN ACCIDENT 
AND TIME AND DISTANCE TRAVELED BY THE VEHICLES IN A MERGING 
VEHICLE ACCIDENT” filed on November 27, 2002 whose inventors are Stefan 
15 Wahlbin, Kathleen E. Rourke, and Kimberly Wiesman is hereby incorporated by 
reference in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/306,803 titled “COMPUTERIZED 
METHOD AND SYSTEM FOR ESTIMATING AN EFFECT ON LIABILITY USING 
A COMPARISON OF THE ACTUAL SPEED OF VEHICLES WITH A SPECIFIED 
20 SPEED” filed on November 27, 2002 whose inventors are Stefan Wahlbin, Kathleen E. 
Rourke, and Kimberly Wiesman is hereby incorporated by reference in its entirety as 
though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/306,908 titled “COMPUTERIZED 
METHOD AND SYSTEM FOR ESTIMATING AN EFFECT ON LIABILITY BASED 
25 ON THE STOPPING DISTANCE OF VEHICLES” filed on November 27, 2002 whose 
inventors are Stefan Wahlbin, Kathleen E. Rourke, and Kimberly Wiesman is hereby 
incorporated by reference in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/306,804 titled “COMPUTERIZED 
METHOD AND SYSTEM FOR ESTIMATING AN EFFECT ON LIABILITY USING 
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CLAIM DATA ACCESSED FROM CLAIM REPORTING SOFTWARE” filed on 
November 27, 2002 whose inventors are Stefan Wahlbin, Kathleen E. Rourke, and 
Kimberly Wiesman is hereby incorporated by reference in its entirety as though fully and 
completely set forth herein. 

5 U.S. Patent Application Serial No. 10/306,866 titled “COMPUTERIZED 

METHOD AND SYSTEM FOR CREATING PRE-CONFIGURED CLAIM REPORTS 
INCLUDING LIABILITY IN AN ACCIDENT ESTIMATED USING A COMPUTER 
SYSTEM” filed on November 27, 2002 whose inventors are Stefan Wahlbin, Kathleen E. 
Rourke, and Kimberly Wiesman is hereby incorporated by reference in its entirety as 
10 though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/306,858 titled “COMPUTERIZED 
METHOD AND SYSTEM FOR ESTIMATING LIABILITY USING RECORDED 
VEHICLE DATA” filed on November 27, 2002 whose inventors are Stefan Wahlbin, 
Kathleen E. Rourke, and Kimberly Wiesman is hereby incorporated by reference in its 
15 entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/306,628 titled “COMPUTERIZED 
METHOD AND SYSTEM FOR ESTIMATING MONETARY DAMAGES DUE TO 
INJURIES IN AN ACCIDENT FROM LIABILITY ESTIMATED USING A 
COMPUTER SYSTEM” filed on November 27, 2002 whose inventors are Stefan 
20 Wahlbin, Kathleen E. Rourke, and Kimberly Wiesman is hereby incorporated by 
reference in its entirety as though fully and completely set forth herein. 

U.S. Patent Application Serial No. 10/422,450 titled “METHOD AND SYSTEM 
FOR DETERMINING MONETARY AMOUNTS IN AN INSURANCE PROCESSING 
SYSTEM” filed on April 24, 2003 whose inventors are Stefan L. Wahlbin and Scott C. 
25 Dulock is hereby incorporated by reference in its entirety as though fully and completely 
set forth herein. 



In Fig. la, an embodiment of an insurance claims processing system 10 may 
include a computer system 20. The term “computer system” as used herein generally 
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includes the hardware and software components that in combination may execute one or 
more computer programs. The term is used broadly to encompass any device or series of 
interconnected devices having at least one processor which executes instructions from at 
least one memory medium. The computer programs may be implemented in software, 

5 hardware, or a combination of software and hardware. A computer system’s hardware 
generally includes a processor, memory media, and Input/Output (I/O) devices. As used 
herein, the term “processor” generally describes the logic circuitry that responds to and 
processes the basic instructions that operate a computer system. The term “memory” is used 
synonymously with “memory medium” herein. The term “memory medium” is intended to 
10 include an installation medium, e.g., a CD-ROM, or floppy disks, a volatile computer 

system memory such as DRAM, SRAM, EDO RAM, Rambus RAM, etc., or a non-volatile 
memory such as optical storage or a magnetic medium, e.g., a hard drive. The memory 
medium may comprise other types of memory as well, or combinations thereof. In addition, 
the memory medium may be located in a first computer in which the programs are executed, 
15 or may be located in a second different computer which connects to the first computer over 
a network. In the latter instance, the second computer provides the program instructions 
to the first computer for execution. Also, the computer system may take various forms, 
including a personal computer system, mainframe computer system, workstation, 
network appliance, Internet appliance, personal digital assistant (PDA), television system 
20 or other device. 

The memory medium preferably stores a software program or programs for 
processing insurance claims as described herein. The software program(s) may be 
implemented in any of various ways, including procedure-based techniques, component- 
25 based techniques, and/or object-oriented techniques, among others. For example, the 
software programs may be implemented using a rule-based development tool such as 
PLATINUM Aion™ available from Computer Associates International, Inc. In one 
embodiment, PLATINUM Aion™ may combine business rule and object-oriented 
technologies to create and maintain complex, knowledge-intensive applications. 
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Software developed with PLATINUM Aion™ may employ an Aion™ programming 
language for automation of processes which may use hundreds or thousands of business 
rules from a knowledge base. An Aion™ inference engine may automatically determine 
which rules to execute, when, and in what order. In various other embodiments, the 
5 software program may be implemented using other technologies, languages, or 

methodologies, as desired. A central processing unit (CPU) executing code and data 
from the memory medium includes a means for creating and executing the software 
program or programs according to the methods, flowcharts, and/or block diagrams 
described below. 

10 

A computer system’s software generally includes at least one operating system, a 
specialized software program that manages and provides services to other software 
programs on the computer system. Software may also include one or more programs to 
perform various tasks on the computer system and various forms of data to be used by the 
15 operating system or other programs on the computer system. The data may include but are 
not limited to databases, text files, and graphics files. A computer system’s software 
generally is stored in non-volatile memory or on an installation medium. A program may be 
copied into a volatile memory when running on the computer system. Data may be read 
into volatile memory as the data is required by a program. 

20 

A server may be defined as a computer program that, when executed, provides 
services to other computer programs executing in the same or other computer systems. 
The computer system on which a server program is executing may also be referred to as a 
server, though it may contain a number of server and client programs. In the client/server 
25 model, a server is a program that awaits and fulfills requests from client programs in the 
same or other computer systems. 

The insurance claims processing system 10 may further include a display screen 
50 connected to the computer system 20 and an insurance database 40 residing on an 
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internal or external storage. The database may also be referred to as a repository. As 
used herein, a “database” may include a collection of information from which a computer 
program may select a desired piece of data. As used herein, an “insurance database” is 
used as a synonym for a “database” when included in or coupled to an insurance claims 
5 processing system 10. System 20 includes memory 30 configured to store computer 
programs for execution on system 20, and a CPU (not shown) configured to execute 
instructions of computer programs residing on system 20. Claims processing program 
60, also referred to as application program software 60, may be stored in memory 30. As 
used herein, an “insurance claims processing program” 60 may include a software 
10 program which is configured to conduct transactions regarding insurance claims, such as 
by estimating the value of the insurance claims, for example. 

The insurance claims processing system 10 may be used by an Insurance 
Company for various embodiments of a system and method for processing insurance 
15 claims using a Table of Contents (TOC). As used herein, an “Insurance Company” (IC) 
includes a business organization that provides insurance products and/or services to 
customers. More particularly, the insurance products may pertain to providing insurance 
coverage for accidents and the trauma-induced bodily injuries that may result due to the 
accident. Examples of trauma-induced bodily injuries may include, but are not limited 
20 to: loss of limb(s); bone fractures; head, neck and/or spinal injury, etc. 

In one embodiment, on receiving a trauma-induced bodily injury, a customer may 
file an insurance claim with his/her insurance organization to cover medical and other 
accident-related expenses. An IC may utilize a computer-based insurance claim 
25 processing system to process insurance claims. In one embodiment, the processing may 
include estimating a value associated with the filed insurance claim. 

As used herein, an “IC business transaction” may be defined as a service of an IC. 
Examples of business transactions include, but are not limited to: insurance transactions 
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such as filing of claims, payment of claims, application for insurance coverage, and 
customized benefits, etc. Business transactions may also include services related to 
customers, insurance providers, employers, insurance agents, investigators, etc. 

5 As used herein, an “IC insurance claim processing system” includes a series of 

instructions executed by a computer system for processing an IC’s business transactions. 
A claim processing system may include one or more processing tasks. A processing task 
may include a sequence of one or more processing steps or an ordered list or a structured 
list of one or more processing steps, associated with the business transaction to be 
10 processed by the claim processing system. In one embodiment, the sequence of steps 
may be fixed. In another embodiment the sequence of steps may be established 
dynamically, in real-time. In one embodiment, the sequence of one or more steps may 
include an initial step, a final step, one or more intermediary steps, etc. In one 
embodiment, an IC user may select steps to process an insurance claim in a sequential 
15 manner. In another embodiment, the IC user may select steps to process an insurance 
claim in a random or arbitrary manner. Examples of processing steps may include, but 
are not limited to: receiving an input from a user of the IC insurance claim processing 
system, reading a value from a database, updating a field in a database, displaying the 
results of a business transaction on a computer screen, etc. 

20 

In one embodiment, the insurance claim processing system utilizes object- 
oriented technology to process insurance claims. In another embodiment, processing of 
insurance claims may utilize traditional programming languages and databases to achieve 
the same result. Insurance objects may be defined to represent or model real-world 
25 business features of insurance products and services. Examples of insurance objects may 
include, but are not limited to, objects representing the following: an insurance claim; an 
accident report; a settlement; an estimated claim; IC service facilities, customers, and 
employees; business processes such as a new insurance application and calculation of a 
premium; interfaces to external insurance organizations; work tasks such as calculations, 
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decisions, and assignments; temporal objects such as calendars, schedulers, and timers; and 
elemental data necessary to accomplish work tasks such as medical costs, risk factors, etc. 



An insurance object may be represented on the computer screen by a graphical icon 
5 or by a display listing the properties of the insurance object in graphic and alphanumeric 
format. An insurance claim object may be configured to gather and evaluate data for 
processing a filed insurance claim and to automatically make decisions about the insurance 
claim. The one or more processing steps associated with the processing of an insurance 
claim may also be configured as one or more processing step objects. In one embodiment, a 
10 display screen may be associated with a processing step. The display screen may also be 
represented as an object. Each display screen object may include a property to point to a 
previous display and another property to point to a next display screen. Each property, e.g. 
the next display pointer on a display screen object, may be changed dynamically by using 
methods associated with the display screen object. One display screen object may serve as 
15 the starting point for processing insurance claims. In one embodiment, the starting point for 
processing insurance claims may include acquiring an insurance claim identification number 
from an IC system user. 

In one embodiment, during the processing of an insurance claim, a business rule 
20 and/or an IC system user input may determine that the insurance claim processing needs the 
execution of additional steps or tasks to continue the processing of the claim. The IC system 
user may provide inputs to the insurance claims processing program 60 at any display screen 
associated with a step included in the Table of Contents (see Fig. 2B for a discussion of the 
generation of the Table of Contents according to one embodiment). The insurance claim 
25 processing software may dynamically modify the number of steps and/or the sequence of 
their execution to complete the claim processing transaction. An IC system user working at 
a client system may then iterate through the claim processing steps and arrive at an 
estimated value for the insurance claim. 
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In one embodiment, upon startup, the program 60 may provide a graphical user 
interface to display claims processing related information on display screen 50. It may 
collect user inputs, entered by using user input devices 52, and associated with insurance 
claims. It may process the user inputs, access an insurance database 40, use the contents 
5 of the insurance database 40 to estimate the insurance claim, and store it in memory 30 
and/or insurance database 40. The program 60 may display a value of the estimated 
insurance claim on display screen 50. A user may view the display of the estimated 
insurance claim on display screen 50, and may interactively make modifications, 
additions, and deletions to the estimated insurance claim. 

10 

System 20 may also include one or more user input devices 52, such as a 
keyboard, for entering data and commands into the insurance claim program 60. It may 
also include one or more cursor control devices 54 such as a mouse for using a cursor to 
modify an insurance claim viewed on display screen 50. In response to the updating of 
15 the estimated insurance claim, the insurance claim program 60 may store the updated 
insurance claim in the insurance database 40. 

Fig. lb illustrates one embodiment of a networked system, configured for 
processing insurance claims. In this embodiment, the system is shown as a client/server 
20 system with the server systems and client systems connected by a network 62. Network 
62 may be a local area network or wide area network, and may include communications 
links including, but not limited to: Ethernet, token ring, internet, satellite, and modem. 
Insurance claims processing system 10 as illustrated in Fig. la may be connected to 
network 62. The insurance claim processing system software and insurance database 40 
25 may be distributed among the one or more servers 70 to provide a distributed processing 
system for insurance claim transactions. In other words, an insurance claim processing 
transaction being processed by the insurance claim processing system may be routed to 
any server based upon the workload distribution among servers 70 at the time of the 
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transaction. Insurance claim processing system servers 70 may be located on a local area 
network or may be geographically dispersed in a wide area network. 



One or more client systems 80 may also be connected to network 62. Client 
5 systems 80 may reside at one or more claim processing units within the insurance 
company. In a wide area network, client systems 80 may be geographically dispersed. 
Client systems 80 may be used to access insurance claim processing system servers 70 
and insurance database 40. An insurance claim-processing employee may use a client 
system 80 to access the insurance claim processing system and execute insurance 
10 transactions. An employee may also use a client system 80 to enter insurance claim 

inputs into the insurance claim processing system. One or more printers 90 may also be 
connected to network 62 for printing documents associated with insurance claim 
transactions. 

15 In Fig. lc, an embodiment of an insurance claims processing system 10 may 

include a computer system 20. In one embodiment, the insurance claims processing 
system may provide context-sensitive help for the processing steps. In one embodiment, 
the context-sensitive help for a step may be automatically invoked and displayed on 
display screen 50 when entering the step. In one embodiment, the user may interactively 
20 invoke context-sensitive help for the step by selecting one or more interface items on the 
display screen 50 with a cursor control device 54 such as a mouse. In one embodiment, 
the user may interactively invoke context-sensitive help for the step by using an input 
device 52. For example, the user may select one or more keys or a combination of keys 
on a keyboard to activate context-sensitive help. The context-sensitive help for each 
25 processing step may be unique, although content may appear in the context-sensitive help 
for two or more processing steps. 

In one embodiment, information for the context sensitive help may be accessed 
from help database 400. Help database 400 may include one or more documents 
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including information that may be useful to a user in performing the various processing 
steps associated with insurance claims processing. Help database 400 may also include 
one or more tables that provide access to the information in the documents. Each table 
may include a plurality of records or entries that may be used to locate help information 
5 about processing steps and/or the elements in processing steps in the one or more 
documents in the help database 400. 

In one embodiment, a search interface may be provided in the insurance claims 
processing system. A user may enter in the search interface one or more terms to be 
10 searched for in help database 400 for the insurance claims processing system. The user 
may then initiate the search for the one or more terms. The insurance claims processing 
system may then search the help database 400 for entries including at least one of the one 
or more terms. The insurance claims processing system may locate one or more entries 
in the help database 400 that include at least one of the one or more terms. The insurance 
15 claims processing system may then display information on display screen 50 from the 
located help database 400 entries. 

Fig. 2 illustrates one embodiment of an insurance claims processing help database 
400 that may be used for context sensitive help and for searching for terms in an 
20 insurance claim processing system. Help database may include one or more index tables 
402, one or more header tables 404, one or more text tables 406, and one or more 
documents 408. One embodiment may include one index table 402, one header table 
404, and one text table 406. In another embodiment, the header table 404 and text table 
406 may be combined into one master table comprising entries for header portions and 
25 text portions of the one or more documents 408. 

Index tables 402, header tables 404, and text tables 406 may each include one or 
more records or entries. The entries in index tables 402 may each include a field 
comprising one or more terms or codes that may be used as keys for locating entries in 
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header tables 404 and/or text tables 406. The entries in index tables 402 may each also 
include information for locating an entry in one of the one or more header tables 404 or 
text tables 406. In one embodiment, an identification number may be used to identify 
each entry in the one or more header tables 404 and text tables 406. The identification 
5 number may be referred to herein as an object ID. In one embodiment, each entry in the 
index tables 402 may include an object ED that identifies, and that may be used to locate, 
one entry in one of the header tables 404 or text tables 406. In one embodiment, index 
tables 402 may include two or more entries that include the same object ED. In other 
words, two or more index table 402 entries may indicate, or point to, the same entry in a 
10 header table 404 or text table 406. Each entry in index tables 402 may be referred to as 
an occurrence of the term or code included in the index table 402 entry in the help 
database 400. 

In one embodiment, each entry in the header tables 404 and text tables 406 may 
15 include a unique object ID that may be used to locate the entry. In one embodiment, each 
entry in the header tables 404 may include a field containing a header or a portion of a 
header from one of the one or more documents 408. Alternatively, each entry in the 
header tables 404 may include information that may be used to locate a header or a 
portion of a header in one of the one or more documents 408. In one embodiment, each 
20 entry in the text tables 404 may include a field containing a text section or a portion of a 
text section from one of the one or more documents 408. Alternatively, each entry in the 
text tables 406 may include information that may be used to locate a text section or a 
portion of a text section in one of the one or more documents 408. 

25 An example of locating headers and text in documents 408 using index tables 402, 

header tables 404 and text tables 406 follows. Index table may include index entries 410 
and 412. Index entry 410 may include a term or code included in a header of one of the 
documents 408. Index entry 410 may include an object ED that may be used to locate 
header entry 414 in one of the header tables 404. Header entry 414 may include a portion 
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or all of header 418 from one of the one or more documents 408. Alternatively, header 
entry 414 may include information that may be used to locate header 418 in one of the 
one or more documents 408. If index entry 410 includes a term, then the term may 
appear one or more times in header 418 and/or in the portion of header 418 included in 
5 header entry 414. If index entry 410 includes a code, then the code may indicate that the 
index table entry 410 refers to a particular header or portion of a header in its entirety 
(i.e., this is not an occurrence of a term). In one embodiment, codes may be used to 
identify headers or sections of text in documents 408. In one embodiment, codes may be 
included as “hidden” text in one or more sections of documents 408, and may be used in 
10 constructing header tables 404 and text tables 406. 

Index entry 412 may include a term or code included in a text section of one of 
the documents 408. Index entry 412 may include an object ID that may be used to locate 
text entry 416 in one of the text tables 406. Text entry 416 may include a portion or all of 
15 text section 420 from one of the one or more documents 408. Alternatively, text entry 
416 may include information that may be used to locate text 420 in one of the one or 
more documents 408. If index entry 412 includes a term, then the term may appear one 
or more times in text section 420 and/or in the portion of text section 420 included in text 
entry 416. If index entry 412 includes a code, then the code may indicate that the index 
20 table entry 412 refers to a particular text section or portion of a text section (i.e., this is 
not an occurrence of a term). 

Embodiments of index tables 402, header tables 404 and text tables 406 are 
further described in Figs. 3, 4, and 5, respectively. 

25 

Fig. 3 illustrates one embodiment of a table including header information from 
one or more documents 408 related to insurance claims processing. The header table 404 
may include a plurality of records, also referred to as entries, with one entry for each 
header element from the one or more documents 408 to be included in a help database 
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400 for the insurance claims processing system. Each entry may comprise a plurality of 
fields, which also may be referred to as elements of the entry. 



An entry may include an object identifier (object ID) 100 for the entry. In one 
5 embodiment, the object ID 100 for the entry may be unique in the help database 400. In 
one embodiment, the object ID 100 may include information that may be used to identify 
the document that includes the header, and the location in the document of the header. 

For example, the object ID 100 of the first entry in the header table 404 of Fig. 3 may 
indicate that the entry is for the header of the first chapter of a first document included in 
10 the help database 400, the object ED 100 of the second entry may indicate that the entry is 
for the header of the first section of the first chapter of the first document, and so on. 

An entry may also include the object identifier of a parent entry (parent ID 102) 
for the entry. For example, the parent ID 102 of the entries for the headers of several 
15 sections in the first chapter of a document may be the object ED 100 of the entry for the 
header of the chapter. 

An entry in the header table 404 may also include information on the location in 
the document of the header. For example, byte count 104 may represent the byte 
20 (character) location in the document of the start of the header. For example, the header of 

the first entry in the header table 404 illustrated in Fig. 3 may start at the first byte of the 
document; the header of the second entry may start at the 26 th byte of the document, etc. 

In one embodiment, an entry in the header table 404 may also include the 
25 alphanumeric text of the header from the document in name field 106. When the entry is 

located during context sensitive help or a search, the header text in name 106 may be read 
from the header table and displayed on the display screen for the user to view. In another 
embodiment, the entry may not store the actual text for the header, but may instead 
include information for locating the text for the header in the document. In this 
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embodiment, when the entry is located, the actual text of the header may be read from the 
document itself and displayed for the user. 

The order of the columns and rows in the header table 404 as illustrated in Fig. 3 
5 is exemplary and is not intended to be limiting. 

Fig. 4 illustrates one embodiment of a table including text information from one 
or more documents 408 related to insurance claims processing. The text table 406 may 
include a plurality of entries, with one entry for each text section from the one or more 
10 documents 408 to be included in the help database 400 for the insurance claims 

processing system. Each entry may comprise a plurality of fields, which also may be 
referred to as elements of the entry. In one embodiment, the fields may be substantially 
similar to the fields in embodiments of the header table 404 as illustrated in Fig. 3. 

15 An entry may include an object identifier 110 (object ID), for the entry. In one 

embodiment, the object ID 1 10 for the entry may be unique in the help database 400. In 
one embodiment, the object ID 1 10 may include information that may be used to identify 
the document including the text section and the location in the document of the text 
section. Object ID 1 10 may also include information to distinguish a text table 406 entry 
20 from a header table 404 entry. For example, a non-zero last digit in the object ID 1 10 
may indicate that the entry is a text table 406 entry and not a header table 404 entry. The 
entry may also include the object identifier of a parent entry (parent ID 1 12) for the entry. 
The parent ID 1 12 may point to an entry in the text table 406 as the parent of the entry. 
The entry may also include a text field 116 that may include some or all of the text from a 
25 section of one of the one or more documents 408 in the help database 400. When the 

entry is located during context sensitive help or a search, the text in text field 116 may be 
read from the text table and displayed on the display screen for the user to view. 
Alternatively, the entry may not store the actual text, but may instead include information 



Atty. Dkt. No.: 5053-63200 



Page 3 1 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C 




for locating the text in the document. In this case, when the entry is located, the actual 
text may be read from the document itself and displayed for the user. 



The order of the columns and rows in the text table illustrated in Fig. 4 is 
5 exemplary and is not intended to be limiting. 

Fig. 5 illustrates one embodiment of an index table 402 for locating terms and/or 
codes for context-sensitive help and for interactively searching for terms in the help 
database 400. Each entry in the index table 402 may represent an occurrence of a term or 
10 code in the one or more documents 408 included in the help database 400 for the 

insurance claims processing system. Examples of documents that may be included in the 
help database 400 for the insurance claims processing system include, but are not limited 
to: medical journals, textbooks and/or manuals, insurance claims processing manuals or 
guidebooks, medical glossaries and/or dictionaries, and documents including context 
15 sensitive help entries for the insurance claims processing steps, and elements of the steps, 
in the insurance claims processing system. 

An entry in the index table 402 may include an object ID 140. The object ID 140 
may indicate a unique entry in a help information table in the help database. In one 
20 embodiment, the help database may include one or more header tables 404 as illustrated 
in Fig. 3 and one or more text tables 406 as illustrated in Fig. 4. 

An entry in the index table may also include a term field 142. In one 
embodiment, term field 142 may include one or more terms located in the one or more 
25 documents 408 in the help database 400. In one embodiment, term field 142 may include 
a code representing a step or page in the insurance claims processing system or an 
element in a step in the insurance claims processing system. The codes may be used in 
invoking context-sensitive help in the insurance claims processing system. One 



Atty. Dkt. No.: 5053-63200 



Page 32 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C 




embodiment may include one or more entries with one or more terms in term field 142 
and one or more entries with codes in term field 142. 

An entry in the index table 402 may also include a Soundex field 144. Soundex is 
5 a commonly used algorithm for encoding words so that similar sounding words encode 
the same. In one embodiment, the first letter of a word to be converted to a Soundex 
equivalent may be copied unchanged, and then subsequent letters may be encoded as 
follows: 

10 b,f,p,v ->"1" 

c, g,j,k,q,s,x,z ,9 -> "2" 

d, t -> "3" 

1 -> "4" 

m,n,n -> "5" 

15 r -> "6" 

Other characters may be ignored and repeated characters may be encoded as 
though they were a single character. Encoding may stop when the resulting string is four 
characters long, adding trailing "0"s if it is shorter. As an example, "SMITH" or 

20 "SMYTHE" may both be encoded as "S530". The Soundex equivalent may be used for 
locating entries in index table when a user mistypes or misspells a word when initiating a 
search. In one embodiment, codes for steps and step elements are not given a Soundex 
equivalent, as a Soundex equivalent of a code is not generally useful. 

25 Columns 146, 148, and 150 may be used during calculation of the relevance of an 

entry. For each entry in the index table 402, column 146 may indicate the position of the 
term or code in the text section or header in which this occurrence of the term or code 
appears. Column 148 may indicate the total count of words in the text section or header. 
For example, in the first entry of the index table 402 as illustrated in Fig. 5, the position 
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column 146 indicates that the term “System” appears as the fifth word of the 54 words 
(from the total words column 148) in the text section indicated by the object ED column 
140. Examining the second entry, the term “System” appears again as the ninth word of 
the same text section. 

5 

In one embodiment, the word count column 1 50 may be used with entries for 
headers in calculating the relevance value 152. Different information and methods may 
be used for calculating the relevance of occurrences of terms and codes appearing in 
headers than the information and methods used to calculate the relevance for terms and 
10 codes appearing in text sections. In calculating the relevance for headers, the percent of 
the total word count indicated in column 150 may be used as part of the calculation. The 
word count 150 indicates how many words make up the one or more words (or words 
represented by a code) as represented in column 142. For example, in the header entry in 
the seventh row of the index table as illustrated in Fig. 5, the term “Anatomy” is in the 
15 third position (as indicated by column 146) of three words (as indicated by column 148) 
and includes one word. Thus, when calculating the relevance, “Anatomy” is 
approximately 33% of the header. 

The last column of the index table 402 illustrated in Fig. 5 may hold a calculated 
20 relevance 1 52 for the occurrence. The relevance may be calculated in advance for all 

occurrences. Alternatively, the relevance for occurrences may not be calculated in 
advance and stored in the index table 402, but instead may be calculated dynamically as 
needed. In one embodiment, columns 146, 148, and 150 may not be stored in the index 
table 402. Instead, the information may be used to calculate the relevance and then 
25 discarded. One embodiment of the index table 402 may include only an object ID 140, a 
term 142, and a relevance value 152. Another embodiment of an index table 402 may 
only include an object ED 140 and a term 142, and the relevance may be calculated 
dynamically. 
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In one embodiment, occurrences in headers may be considered of higher 
relevance than occurrences in text sections. Therefore, different methods may be applied 
to calculate the relevance of occurrences in headers than are applied to calculate the 
relevance of occurrences in text sections. In one embodiment, relevance values may be 
5 scaled to be between 0.0 and 1 .0, with 1 .0 being the highest relevance. In one 

embodiment, the relevance may be calculated so that a relevance value of 0.0 does not 
occur. Note that any scale may be used for the relevance calculation, as it may be the 
ordering of the relevance values that is useful, and not necessarily the scale on which the 
relevance values are calculated. 

10 

In one embodiment, a maximum relevance value may be provided for occurrences 
in text sections. This maximum value may be applied as a weight or scaling factor during 
the relevance calculation. In one embodiment, the maximum relevance value for 
occurrences in text sections may also serve as the minimum value for occurrences in 
15 headers. In this embodiment, header occurrences may always have at least as high a 
relevance value as the highest relevance text occurrences. In another embodiment, 
header occurrences may always have a higher relevance value than the highest relevance 
text occurrences. 

20 The following is an example of using the tables in Figs. 3, 4 and 5 for context- 

sensitive help in an insurance claims processing system. A user of the insurance claims 
processing system may begin processing of an insurance claim. The system may enter 
the first step in the processing of the claim. The first step may be displayed in a “page” 
on the display screen for the user. Information about the first step and the display page 
25 for the first step may be stored in the computer executing the insurance claims processing 
system. In this information, a code for the step, which may also be viewed as a code for 
the page, may be stored. When the step is entered, the code may be read from the 
information, and the context-sensitive help system may search the index table 402 for one 
or more entries with a code in term field 142 matching the code for the step. Upon 
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locating the one or more entries in the index table 402, the context-sensitive help system 
may locate one or more entries in the header tables 404 and/or text tables 406 in the help 
database 400 corresponding to the object IDs 140 in the entries in the index table 402. 

The header and text from the located one or more entries in the header tables 404 and/or 
5 text tables 406 may then be displayed as help information items on the display screen for 
the user. There may be one help information item displayed for each located entry in the 
index table 402. In one embodiment, the help information items may be displayed in an 
order of relevance using the relevance values 152 for the located entries in the index table 
402. 

10 

Elements within a step may also be given a code, and the code may be included in 
one or more entries in the index table 402. When a step in insurance claims processing is 
entered, one or more codes for one or more elements of the step may also be read from 
stored information about the step. Occurrences of help information for the one or more 
15 codes may be searched for, ranked by relevance, and displayed similarly to, and along 
with, the code for the step as described above. 

The order of the columns and rows in the index table 402 illustrated in Fig. 5 is 
exemplary and is not intended to be limiting. 

20 

Fig. 6a is a flow diagram illustrating one embodiment of a mechanism for 
generating an insurance claims processing help database 400. In step 430, one or more 
documents may be processed into header tables 404 and text tables 406. In one 
embodiment, one entry is added to a header table 404 for each header in the one or more 
25 documents 408 in the help database 400. In one embodiment, one entry may be added to 
a text table 406 for each text section in the one or more documents 408 in the help 
database 400. An object ID may be assigned to each entry added to a header table 404 or 
text table 406. A parent ID of each entry may also be identified. The number of bytes in 
the section of text or header for the entry may also be determined. In one embodiment, 
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the entry for each occurrence may include the object ID, parent ID, byte count and text 
section for text table 406 entries or header text for header table 404 entries. 

In step 432, one or more index tables 402 may be generated. In one embodiment, 
5 a plurality of terms may be searched for in the header text of the entries in the one or 
more header tables 404 and in the text section of the entries in the one or more text tables 
406. Each located occurrence of each term may be recorded as an entry in an index table 
402. In one embodiment, one or more codes may be associated with headers and/or text 
sections in the one or more documents, and the one or more codes may be searched for in 
10 the header tables 404 and text tables 406. Each located occurrence of each code may be 
recorded as an entry in an index table 402. In one embodiment, a code may be used to 
identify a particular section of text or header in the one or more documents 408. For 
example, a code may be used to identify a section of text that may be displayed as the 
context sensitive help for a step in the insurance claims processing step. In one 
15 embodiment, an entry may be added to the index table for each occurrence of a term or 

code located in the name field 106 of an entry in a header table 404 or in the text field 
1 16 of an entry in a text table 406. In step 434, the object ID of the header table 404 
entry or text table 406 entry where each occurrence was located may be inserted in the 
object ID field 140 of the index table 402 entry for the occurrence. 

20 

In step 436, one or more other fields may be added to the entries in the index table 
402. In one embodiment, a Soundex equivalent 144 may be added to entries that include 
a term in the term field 142. In one embodiment, a Soundex equivalent 144 may not be 
added for entries with a code in the term field 142. In one embodiment, for each entry in 
25 the index table 402, the position of the term or code in the text section or header in which 

this occurrence of the term or code appears may be entered in a position field 146. In one 
embodiment, the total count of words in the text section or header may be entered in a 
total words field 148. In one embodiment, for each header table 404 entry in the index 
table 402, a word count 150 may be entered that indicates the number of words in the 
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term 142 for this occurrence. In one embodiment, for occurrences in text tables 406, a 
word count of zero may be entered. 



In step 438, the relevance value 152 for each occurrence may be calculated and 
5 entered in index table 402. In one embodiment, the relevance value 152 for each 

occurrence may be calculated up front, when the help database tables are generated. In 
another embodiment, the relevance value 152 for an occurrence may be calculated 
dynamically when the occurrence is located for display in the insurance claims 
processing system. In this embodiment, the index table 402 may not include a relevance 
10 value 152 for each occurrence. 

Figs. 6b through 6h expand on step 438 of Fig. 6a and further describe several 
embodiments of a mechanism for calculating the relevance values 152 of occurrences in 
the help database. In Fig. 6b, the relevance values 1 52 for occurrences in text sections of 
15 the one or more documents may be calculated in step 450. In step 452, the relevance 
values 152 for occurrences in headers of the one or more documents may be calculated. 

In one embodiment, a different mechanism may be used to calculate the relevance values 
152 for occurrences in headers than the mechanism used to calculate the relevance values 
1 52 for occurrences in text sections. 

20 

Fig. 6c expands on step 450 of Fig. 6b and further describes one embodiment of a 
mechanism for calculating relevance values 152 for occurrences in text sections of the 
one or more documents in the help database. In step 460, the position 146 of the 
occurrence in the text section may be subtracted from the total words 148 for the text 
25 section. In one embodiment, the words in the text section may be numbered in a 

sequence from a first word to a last word. In one embodiment, the first word may be 
numbered as word 0, and the last word as word (N - 1), where N is the total number of 
words in the text section. In another embodiment, the first word may be numbered as 
word 1 , and the last word as word N, where N is the total number of words in the text 
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section. In this embodiment, in step 462, the results of step 460 may be incremented by 
one, which may be effective to prevent the relevance value from being zero. For 
example, applying step 460 to word 10 in a section with 10 words produces (10 - 10) = 0. 
Incrementing by one thus may assure that a relevance of zero is not produced. One 
5 skilled in the art will recognize that there may be various other methods for assuring that 
a relevance of zero is not produced. In yet another embodiment, the words may be 
numbered in reverse order, with the first word in the text section being numbered as word 
N, and the last word as word 1 . In this embodiment, steps 460 and 462 may not be 
performed. 

10 

In step 464, the results of step 462, or the results of step 460 in embodiments in 
which step 462 is not performed, may be divided by the total words 148 for the text 
section to produce a ratio R1 that may represent the relevance value 152 for the text 
occurrence. In embodiments where steps 460 and 462 are not performed, in step 464, the 
15 word number of the term in the text section may be divided by the total words 148 to 
produce the ratio R1 . In one embodiment, the ratio R1 may be in the range (0 < R1 <= 

1 .0). In one embodiment, occurrences in headers may be considered more relevant than 
occurrences in text sections. In this embodiment, in step 466, R1 may be multiplied by a 
first scaling factor SI to lower the relevance values of text section occurrences in relation 
20 to occurrences in headers. For example, a scaling factor SI of 0.33 may be applied to R1 . 
Thus, in one embodiment, after step 466, R may be in the range (0 < R1 <= SI). 

In one embodiment, in step 467, the output of step 466, or the output of step 464 
in embodiments where step 466 is not performed, may be rounded to a number of 
25 significant digits. Various rounding methods may be used including rounding up, 

rounding down, and rounding to the nearest value. For example, if two significant digits 
are desired, the results may be rounded to produce results in the range (0.01-1.00) 
inclusive. In step 468, the results are output as the relevance value 152 for the occurrence 
in the text section. In one embodiment, the output relevance value 1 52 may be written to 
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the index table 142. 



The following is an example of applying one embodiment of a mechanism for 
calculating the relevance value for a text occurrence and is not intended to be limiting in 
5 any way. The first row of the index table 402 as illustrated in Fig. 5 shows that the term 
“System” appears as the fifth of 54 words in a text section. A first scaling factor SI of 
0.33 is to be applied and the results rounded to two significant digits. Applying the steps 
of Fig. 6c: 

10 Step 460: 54 - 5 = 49 

Step 462: 49 + 1 = 50 

Step 464: 50/54= @0.925925 

Step 466: 0.925925 * 0.33 = 0.30555525 

Step 467: Round (0.30555525) = 0.31 

15 

Fig. 6d expands on step 452 of Fig. 6b and further describes one embodiment of a 
mechanism for calculating relevance values 1 52 for occurrences in headers of the one or 
more documents in the help database. In step 470, a first relevance value based on the 
position of the term in the header may be calculated. In step 472, a second relevance 
20 value based on the percentage of the header the term occupies may be calculated. In step 
474, the positional and percentage relevance values may be combined. In one 
embodiment, occurrences in headers may be considered more relevant than occurrences 
in text sections. In this embodiment, in step 476, the relevance value may be adjusted 
using a first scaling factor to adjust the relevance value in relation to the relevance values 
25 of occurrences in text sections. In one embodiment, in step 477, the output of step 476, 

or the output of step 474 in embodiments where step 476 is not performed, may be 
rounded to a number of significant digits substantially similarly to the rounding method 
used in step 467 of Fig. 6c. In step 478, the results may be output as the relevance value 
152 for the occurrence in the header. In one embodiment, the output relevance value 152 
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may be written to the index table 142. 



Fig. 6e expands on step 470 of Fig. 6d, illustrating one embodiment of a 
mechanism for calculating the positional relevance of an occurrence in a header. In one 
5 embodiment, this mechanism may be substantially similar to the mechanism described in 
steps 460 to 464 of Fig. 6c. In step 480 of Fig. 6e, the position 146 of the occurrence in 
the header may be subtracted from the total words 148 for the occurrence. In one 
embodiment, in step 482, the results of step 480 may be incremented by one, which may 
be effective to prevent the relevance value from being zero. One skilled in the art will 
10 recognize that there may be various other methods for assuring that a relevance of zero is 
not produced. In step 484, the results of step 482, or the results of step 480 in 
embodiments in which step 482 is not performed, may be divided by the total words 148 
for the occurrence to produce a ratio R2 that may represent the relevance value 1 52 for 
the header occurrence. The ratio R2 may be in the range (0 < R2 <= 1). 

15 

Fig. 6f expands on step 472 of Fig. 6d, illustrating one embodiment of a 
mechanism for calculating the percentage relevance of an occurrence in a header. In one 
embodiment, a term may include one or more words. In step 486, the number of words 
150 in the term 142 may be divided by the total number of words 148 in the header to 
20 produce the percentage of the header occupied by the term. For example, if a term 

comprises two words, and a header where an occurrence of the term is found comprises 
three words, then the percentage relevance may be calculated as 2 / 3 = 0.667. 

Fig. 6g expands on step 474 of Fig. 6d and illustrates one embodiment of a 
25 mechanism for combining the positional relevance as calculated in Fig. 6e and the 
percentage relevance as calculated in Fig. 6f for an occurrence in a header. In one 
embodiment, the positional relevance may be multiplied by a second scaling factor S2 in 
step 490. In step 492, the percentage relevance may be multiplied by (1 - S2). In one 
embodiment, the percentage relevance may be considered more important than the 
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positional relevance, and thus the percentage relevance may be given a larger weight than 
the positional relevance. For example, S2 may be assigned a value of 0.33, and the 
positional relevance multiplied by S2. The percentage relevance may then be multiplied 
by (1 - S2) = 0.67. In step 494, the scaled position and percentage relevance values may 
5 be added to produce the relevance value for the occurrence in the header. 

In one embodiment, occurrences in headers may be considered more relevant than 
occurrences in text sections. Fig. 6h expands on step 476 of Fig. 6d and illustrates one 
embodiment of a mechanism for adjusting the header relevance value in relation to the 
10 relevance values of occurrences in text sections. In step 496, the header relevance value 
results of step 494 may be multiplied by (1 - SI), where SI is the first scaling factor as 
described in step 466 of Fig. 6c. For example, if SI = 0.33, then the combined relevance 
value may be multiplied by (1 - 0.33) = 0.67. In one embodiment, the scaled header 
relevance value may then be adjusted by adding the first scaling factor SI to the header 
15 relevance value, so that the minimum header relevance value is higher than the maximum 
text section relevance value. For example, if SI = 0.33, then the maximum text section 
relevance value may be 0.33. By applying step 498, the minimum header relevance value 
may be 0.34. In one embodiment, after performing steps 496 and 498, a header relevance 
value R3 may be within the range ((SI + 1) <= R <= 1.0). 

20 

The following is an example of applying one embodiment of a mechanism for 
calculating the relevance value for a header occurrence and is not intended to be limiting 
in any way. The eighth row of the index table 402 as illustrated in Fig. 5 shows that the 
term “Anatomy” appears as the second of five words in a header. A first scaling factor 
25 SI = 0.33 and a second scaling factor S2 = 0.3 are to be used, and the results rounded to 
two significant digits. Applying the steps of Fig. 6d-6h: 

Step 470 (Fig. 6e): 

Step 480: 5 -2 = 3 
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Step 482: 


3 + 1=4 


Step 484: 


4/5 = 0.8 


Step 472 (Fig. 6f): 


Step 486: 


1/5 =0.2 


Step 474 (Fig. 6g): 


Step 490: 


0.8 * 0.3 = 0.24 


Step 492: 


0.2 * (1.0 - 0.3) = 0.14 


Step 494: 


0.24 + 0.14 = 0.38 


Step 476: 


Step 496: 


0.38 *(1.0 -0.33) = 0.2546 


Step 498: 


0.2546 + 0.33 = 0.5846 



Step 477: 

Round (0. 5846) = 0.58 



15 Figs. 7a through 7c are flow diagrams describing embodiments of a mechanism 

for providing context-sensitive help in an insurance claims processing system. Fig. 7a 
illustrates a high-level view of the entire process, while Figs. 7b and 7c give more detail 
of various steps of Fig. 7a. 

20 In Fig. 7a, a user may initiate processing of an insurance claim in the insurance 

claims processing system in step 300. The insurance claims processing may begin at a 
first processing step, and may continue through a number of processing steps until the 
insurance claim has been processed. A next processing step may be determined by the 
user input at a current processing step. Each processing step may be displayed to the user 
25 in one or more pages on a computer display screen. 

In step 302, the claims processing system may enter a processing step and display 
a page for the processing step. In step 304, the context-sensitive help for the page may be 
invoked. Context-sensitive help for each processing step may be unique, although 
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content may appear in the context-sensitive help for two or more processing steps. 
Context-sensitive help may also be unique for each of the one or more pages within a 
processing step. In step 306, the page for the processing step may be displayed along 
with the context-sensitive help for the page. In one embodiment, the context-sensitive 
5 help for the page may instead replace the display of the page for the processing step. In 
one embodiment, the displayed page may occupy substantially the entire display screen 
on the display device. In another embodiment that supports windows, the page may be 
displayed in a window on the display screen. In one embodiment, the page may be 
divided into two or more panes, the context-sensitive help may be displayed in one or 
10 more panes on the page, and the processing step contents may appear in one or more 
panes on the page. 

Fig. 7b illustrates step 304 of Fig. 7a in more detail. In step 304 of Fig. 7a, the 
context-sensitive help for the page is invoked. In step 308, items to be searched for in the 
15 context-sensitive help system may be determined. In one embodiment, each page in the 
insurance claims processing system may have a unique code, which may be referred to as 
a page ED. The page ID for the invoked page may be read. In one embodiment, the page 
ID may be stored with information describing the page that is read by the claims 
processing system prior to displaying the page. The information may describe the format 
20 and contents of the page. Alternatively, the page ID may be “hardcoded” into the code of 
the claims processing system. 

The page may include one or more elements that have associated codes. The 
codes for the one or more elements on the page may also be read. In one embodiment, 

25 the elements on the page may be system-supplied “answers” to questions posed to the 
user during the claims processing. In one embodiment, the answers may be 
classifications for injuries, anatomical regions, etc. used during injury claims processing. 
In another embodiment, instead of reading codes for the elements, the text of the 
elements may be read. 
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In step 310, the insurance claims processing system may search one or more index 
tables as illustrated in Fig. 6 for entries including the page ID that may be used to locate 
help entries for the page in one or more help tables as illustrated in Figs. 4 and 5. The 
5 index table may also be searched for entries for the elements of the page. In one 
embodiment, a code for an element is used to search the one or more index tables for 
entries. In another embodiment, the text of the elements is used to search the one or more 
index tables for entries. 

10 In step 312, one or more entries may be located in the one or more index tables. 

In one embodiment, there will be at least one entry located for the page ID in the one or 
more index tables. In one embodiment, if elements of the page have an associated code, 
there will be at least one entry located for each code in the one or more index tables. In 
one embodiment, each entry in the one or more index tables may indicate an occurrence 
15 in the one or more documents included in the help database for the insurance claims 
processing system of the page ID, code, or term included in the index table entry. 

In step 314, entries may be located in one or more help tables using information 
from the entries located in the one or more index tables for the page ID and any elements 
20 of the page. The help tables may be substantially similar to the tables illustrated in Figs. 

4 and 5. In one embodiment, each entry in an index table includes an object ID. The one 
or more help tables may be searched for occurrences of the object ED in each located 
entry. In one embodiment, the object ED may include information used to determine 
which help table the object ED is found in. For example, the last two digits of the object 
25 ID may indicate if the object ID is an entry for a header table similar to the one illustrated 
in Fig. 4 or for a text table similar to the one illustrated in Fig. 5. In one embodiment, 
there may be one entry in the help tables for each object ID. In one embodiment, a 
particular object ED may be included in one or more entries in an index table. 
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Fig. 7c illustrates step 306 of Fig. 7a in more detail. In step 306 of Fig. 7a, the 
context-sensitive help for the page may be displayed. In step 320 of Fig. 7c, the located 
help table entries may be ranked by relevance. In one embodiment, the entries in the 
index table may include a relevance value. The located help table entries may be ranked 
5 from highest relevance to lowest relevance. Entries with the same relevance may be 
ranked by any of several methods, including, but not limited to: alphabetic ranking and 
order of appearance in the index table. In one embodiment, the located help table entries 
may be listed without ranking for relevance. In one embodiment, any entries found for 
the page code may be displayed at the top of the list regardless of the relevance ranking 
10 of the entry. Entries for other codes in the page may then be ranked below the page code 

entry or entries in order of relevance. In one embodiment, when there is more than one 
term being searched for, located entries may be first ranked on the number of search 
terms the entries include. A header or text section of a document may include one or 
more occurrences of the page ID, codes, or terms being searched for. Entries that include 
15 more search terms may be ranked higher than entries with fewer search terms. The 
entries within the ranking categories may then be ranked by relevance within the 
category. Thus, entries with lower relevance, but more search terms, may appear higher 
in the overall ranking than entries with higher relevance, but fewer search terms. 

20 In step 322, information from the located help table entries may be displayed. In 

one embodiment, the entries may be displayed in the order of relevance as determined in 
step 320. The help table entries may include portions of text from one or more 
documents related to insurance claims processing. Some help table entries may include 
section headers from the one or more documents. Some help table entries may include 
25 text from the bodies of sections of the one or more documents. Some help entries may 
include glossary information from the one or more documents. Other entries may include 
text from other portions of the one or more documents. In one embodiment, the 
relevance value may also be displayed. 
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In step 324, information describing the location of the displayed portions of text 
in the one or more documents may be displayed. This information may allow the user to 
look up (electronically or manually) located occurrences in the one or more documents. 
The location information may include, but is not limited to: document title, chapter title, 

5 and/or number, chapter or section header, section number and/or title, page number, 
number of occurrences in the section, etc. 

In one embodiment, the page display may be split into sections, or panes. In one 
embodiment, the information from the located help table entries may be displayed in a 
10 first pane; the information describing the location in the one or more documents of 
displayed portions of text may be displayed in a second pane; and the step information 
may be displayed in a third pane. In one embodiment, separate windows may be used to 
display the information from the located help table entries, the locations in the one or 
more documents, and the step information. 

15 

Fig. 8 illustrates one embodiment of a display screen 200 showing multiple panes, 
wherein two of the panes comprise context sensitive help information for a step and the 
elements of the step. In this embodiment, pane 202 may display a step in the processing 
of an insurance claim. One or more step elements 203 may be displayed in pane 202. 

20 One or more context sensitive help occurrences for the step may be displayed in pane 
230. One or more context sensitive help occurrences for the elements in the step may 
also be displayed in pane 230. Locations for the context sensitive help occurrences 
displayed in pane 230 may be displayed in pane 232. In one embodiment, a location may 
be displayed as a chapter hierarchy of the document in which the occurrence is found. 

25 

Fig. 9 is a flow diagram illustrating one embodiment of a mechanism for 
searching for insurance claims processing terms. In one embodiment, the search 
mechanism may use the same one or more index tables and one or more help tables as are 
used in the mechanism for providing context sensitive help as described in Figs. 7a-7c. 
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A user may first initiate processing of an insurance claim in the insurance claims 
processing system. The insurance claims processing may begin at a first processing step, 
and may continue through a number of processing steps until the insurance claim has 
5 been processed. A next processing step may be determined by the user input at a current 
processing step. Each processing step may be displayed to the user in one or more pages 
on a computer display screen. The claims processing system may enter a processing step 
and display a page for the processing step. 

10 A search interface may be presented to the user on the display screen. In one 

embodiment, the search interface may be displayed in response to user action. For 
example, the user may activate a button or menu item to cause the system to display the 
search interface. The search interface may be presented in any of various forms. For 
example, a text entry box may be displayed that accepts one or more terms or phrases to 
15 be searched for, and a button may be displayed that initiates a search when activated by 
the user. The text entry box may also accept special characters, for example, quotation 
marks around a group of terms that are to be searched for as a phrase. The text entry box 
may also accept logical operators; for example, an AND operator may be entered 
between two terms to indicate that help table entries are to be searched for that include 
20 both terms. 

In step 350, the user may enter in the search interface one or more terms to be 
searched for in the help database for the insurance claims processing system. The user 
may then initiate the search for the one or more terms. In step 352, the insurance claims 
25 processing system may search the one or more index tables for entries including at least 
one of the one or more terms. 

In step 354, one or more entries may be found in the one or more index tables that 
include at least one of the one or more terms. In step 356, the located entries in the index 
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table may be used to locate help entries in the one or more help tables that include at least 
one of the one or more terms. In one embodiment, each entry in an index table includes 
an object ID. The one or more help tables may be searched for occurrences of the object 
ED from each of the located entries. 

5 

In step 358, the located help table entries may be ranked by relevance. In one 
embodiment, the entries in the index table may include a relevance value. The located 
help table entries may be ranked from highest relevance to lowest relevance. Entries with 
the same relevance may be ranked by any of several methods, including, but not limited 
10 to: alphabetic ranking and order of appearance in the index table. 

In one embodiment, more than one term may be searched for, and located entries 
may be first ranked on the number of search terms the entries include. Entries that 
include more search terms may be ranked higher than entries with fewer search terms. 

15 For example, if the user enters three terms to be searched for, entries that include all three 
of the search terms may be ranked first, then entries that include two of the search terms, 
and finally entries that include just one of the search terms. The entries within the 
ranking categories may then be ranked by relevance within the category. Thus, entries 
with lower relevance, but more search terms, may appear higher in the overall ranking 
20 than entries with higher relevance, but fewer search terms. 

In one embodiment, if there is more than one term being searched for, 
occurrences including more than one of the search terms may be listed once, rather than 
listing the occurrence for each search term included in the occurrence. A relevance value 
25 of occurrences including more than one search term may be calculated from the relevance 
value of each of the terms included in the occurrence. For example, if a search is 
initiated for the terms “Anatomy” and “Body,” and the index table 402 illustrated in Fig. 

5 is searched, the term “Anatomy” will be located in the third entry in the table, and the 
term “Body” in the fourth entry. The third and fourth entries have the same object ID 
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140, indicating that these occurrences are from the same text section. In one 
embodiment, only one occurrence may be displayed on the display screen for the text 
section entry in text table 406 indicated by the object ID 140 of entries two and three in 
index table 402. In one embodiment, the relevance value for an occurrence including 
5 more than one term may be calculated using the following method: 

Relevance Value = Sum of Occurrence Relevance Values / Number of Occurrences 

Applying this method to the relevance values 152 of the third and fourth entries in index 
10 table 402: 

(0.28 + 0.25) / 2 = 0.265 

In one embodiment, the calculated relevance value for the occurrence including the two 
15 search terms (0.265) may then be rounded to 0.27. In one embodiment, the calculated 
relevance value may then be used in ranking the occurrence including two terms against 
other occurrences including two terms. 

In step 360, information from the located help table entries may be displayed. In 
20 one embodiment, the entries may be displayed in the order of relevance as determined in 
step 358. The help table entries may include portions of text from one or more 
documents related to insurance claims processing that include one or more of the one or 
more search terms. Some help table entries may include section headers from the one or 
more documents. Some help table entries may include text from the bodies of sections of 
25 the one or more documents. Some help entries may include glossary information from 
the one or more documents. Other entries may include text from other portions of the 
one or more documents. In one embodiment, the relevance value may also be displayed. 
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In step 362, information describing the location of the displayed portions of text 
in the one or more documents may be displayed. This information may allow the user to 
look up (electronically or manually) located occurrences in the one or more documents. 
The location information may include, but is not limited to: document title, chapter title, 

5 and/or number, chapter or section header, section number and/or title, page number, 
number of occurrences in the section, etc. 

In one embodiment, the page display may be split into sections, or panes. In one 
embodiment, the information from the located help table entries may be displayed in a 
10 first pane; the information describing the location in the one or more documents of 
displayed portions of text may be displayed in a second pane; and the step information 
may be displayed in a third pane. In one embodiment, separate windows may be used to 
display the information from the located help table entries, the locations in the one or 
more documents, and the step information. 

15 

Figs. 10 and 10a illustrates embodiments of a display screen 200 showing 
multiple panes, wherein two or more of the panes comprise search results information. 
Referring to Fig. 10 for a description of display screen 200, pane 202 may display a page 
for a step in the processing of an insurance claim. The search term “cuboid” 208 has 
20 been previously entered by the user, and a search was initiated and completed. 

In pane 204, occurrences of the search terms (located entries in the one or more 
help tables) may be displayed. Column 210 of pane 204 may display a location where 
the term is found. In one embodiment, a portion or all of a text section or a portion or all 
25 of a header from a document may be displayed in column 210. Column 212 may display 
a portion or all of a chapter or section title of the document where the occurrence is 
located. Column 214 may list the search term(s) that appear in the occurrence. In this 
example, only one term 208 was entered. If multiple search terms are entered, then all 
search terms that appear in a listed occurrence may be listed in column 214. Column 216 
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may display the number of search terms found in the occurrence. Column 218 may 
display the relevance value for the entries. In this example, all displayed entries have the 
same relevance value (1). Other embodiments may include more or fewer columns 
displaying the same or other information about the occurrences. In one embodiment, not 
5 all located entries may be displayed in pane 204. An interface item or items may be 
provided to the user to display other located entries. Interface items may be items 
displayed graphically on the screen (for example, icons) and selectable using input/output 
devices such as a mouse, joystick, or arrow keys on a keyboard. Interface items may also 
be keyboard selections such as function keys or key combinations. For example, a button 
10 may be provided that allows the user to scroll down the list of located entries in pane 204. 

In pane 206, information about the location of the occurrences in pane 204 may 
be displayed. Column 220 may display chapter numbers and/or chapter headers from the 
one or more documents in the help database that include one or more of the located 
15 occurrences displayed in pane 204. In one embodiment, there may be one entry in pane 
206 for each entry in pane 204. Alternatively, there may be one entry in pane 206 for 
each chapter that includes at least one of the occurrences displayed in pane 204. An 
interface item or items may be provided to allow the user to display entries not currently 
displayed in pane 206. 

20 

Fig. 1 1 shows the display screen 200 of Fig. 10, with one of the search results 
panes (pane 204) hidden to provide more display area for claims processing information. 
In this embodiment, pane 206 is moved nearer to the top of the display screen than in the 
display screen illustrated in Fig. 10. Pane 202 displays the page for a step in the 
25 processing of an insurance claim. Pane 202 has been expanded to provide more lines for 
displaying the elements of the step than in the display screen illustrated in Fig. 10. Thus, 
in this example, pane 202 of Fig. 1 1 displays the step element “Injury Description” 220 
which was hidden in pane 202 of Fig. 10. 
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An interface item or items may be provided to the user for hiding or showing one 
or more panes displaying portions of the search results or context-sensitive help. 

Interface items may be items displayed graphically on the screen (for example, icons) 
selectable using input/output devices such as a mouse, joystick, or arrow keys on a 
5 keyboard. Interface items may also be keyboard selections such as function keys or key 
combinations. For example, a function key or key combination may be provided to 
toggle between hiding and showing pane 204. 

The example illustrated in Fig. 1 1 is of a display with search results. In one 
10 embodiment, the hiding and showing of panes as described above may be applied to 
displays with panes displaying context-sensitive help for a step. 

The ability to hide portions of search results or context-sensitive help may be 
useful in insurance claims processing systems with displays that have a limited amount of 
15 display space. For example, displays on some terminals may be limited to 24 lines of 
text. If the search results are displayed in two panes each using eight lines, hiding one of 
the panes may double the display space for the step elements from eight to sixteen lines. 

Fig. Id is a network diagram of an illustrative distributed computing environment 
20 which is suitable for implementing various embodiments. The distributed computing 
environment may include various server systems 70A and client systems 80A connected 
by a network 55A. Other networkable devices such as printers 90A may also be 
connected to the network 5 5 A. The servers 70A, clients 80A, and other devices may be 
geographically dispersed. A single computer system may serve as both a server and 
25 client. 



The network 55 A may be a local area network or wide area network, and may 
include communications links including, but not limited to: Ethernet, token ring, 
Internet, satellite, wireless, telephone, cable, DSL, and other suitable pathways. As used 
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herein, “the Internet” includes one or more substantially global networks which are 
generally accessible by the public (i.e., they are not proprietary or not largely 
characterized by controlled access). Various sources of data on the Internet may be 
accessed through protocols such as HTTP (HyperText Transport Protocol), HTTPS 
5 (Secure HyperText Transport Protocol), FTP (File Transfer Protocol), Telnet, NNTP 
(Network News Transport Protocol), SMTP (Simple Mail Transfer Protocol), and other 
suitable protocols. Transmission of data over the Internet is typically achieved through 
the use of TCP/IP (Transmission Control Protocol/Intemet Protocol) packets. 

10 Fig. 2aA is an illustration of an insurance claims processing server computer 

architecture according to one embodiment. Fig. 2bA is an illustration of an insurance 
claims processing client computer architecture according to one embodiment. The 
insurance claims processing server 70A may include a computer system 20aA with a 
memory 30aA. The insurance claims processing client 80A may include a computer 
15 system 20bA with a memory 30bA. 

The insurance claims processing server 70A may further include a display device 
50aA connected to the computer system 20aA and an insurance database 40A residing on 
an internal or external storage. Computer system 20aA may include memory 30aA 
20 configured to store computer programs for execution on the computer system 20aA and a 
central processing unit (or CPU, not shown) configured to execute instructions of 
computer programs residing on the computer system 20aA. Insurance claims processing 
server software 60A may be stored in the memory 30aA. 

25 The insurance claims processing client 80A may further include a display device 

50bA connected to the computer system 20bA. Computer system 20bA includes memory 
30bA configured to store computer programs for execution on the computer system 20bA 
and a central processing unit (or CPU, not shown) configured to execute instructions of 
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computer programs residing on the computer system 20bA. Insurance claims processing 
client software 68 A, such as web browser software, may be stored in the memory 30bA. 



The insurance claims processing server 70A may be connected to network 55A. 

5 The insurance claims processing server software 60A and insurance database 40A may be 
distributed among the one or more servers 70 A to provide a distributed processing system 
for insurance claim transactions. In other words, an insurance claim processing 
transaction being processed by the insurance claim processing system may be routed to 
any server based upon the workload distribution among servers 70A at the time of the 
10 transaction. Insurance claim processing system servers 70 A may be located on a local 
area network or may be geographically dispersed in a wide area network. 

One or more clients 80A may also be connected to network 55A. Clients 80A 
may reside at one or more claim processing units within the insurance company. In a 
15 wide area network, clients 80A may be geographically dispersed. Clients 80A may be 
used to access one or more insurance claim processing system servers 70A and associated 
insurance databases 40A. An insurance claim processing employee may use a client 80A 
to access the insurance claim processing system and execute insurance transactions. An 
employee may also use a client 80A to enter insurance claim inputs into the insurance 
20 claim processing system. As shown in Fig. Id, one or more printers 90A may also be 
connected to network 55 A for printing documents associated with insurance claim 
transactions. 

Systems 20aA and 20bA may also include one or more users input devices 52aA 
25 and 52bA, such as a keyboard, for entering data and commands into the insurance claim 
program 60A. It may also include one or more cursor control devices 54aA and 54bA 
such as a mouse for using a cursor to modify an insurance claim viewed on display screen 
50aA and/or 50bA. In response to the updating of the estimated insurance claim, the 
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insurance claim server software 60A may store the updated insurance claim in the 
insurance database 40A. 



The insurance claims processing server 70A and client 80A may be used by an 
5 Insurance Company for various embodiments of a system and method for processing 
insurance claims. 

Fig. 3 aA is an illustration of an insurance claims processing server software 60A 
architecture for a single client according to one embodiment. The server software 60A 
10 may include an insurance processing rules engine 61 A. As used herein, a “rules engine” 
may include an expert system which is operable to produce an output as a function of a 
plurality of rules. A rules engine, in one embodiment, may include an expert computer 
system which utilizes and builds a knowledge base developed in the form of business 
rules and/or formulas to assist the user in decision-making. In one embodiment, the rules 
15 engine 61 A is operable to generate insurance claim assessment questions to be displayed 
to a user during an insurance claim consultation session. The rules engine 61 A may also 
be operable to estimate a value of an insurance claim as a function of insurance claim 
assessment data entered by a user in response to the insurance claim assessment 
questions. In one embodiment, the insurance claim may include a bodily injury claim, 

20 the insurance claim assessment questions may include bodily injury claim assessment 

questions, the insurance claim assessment data may include bodily injuries and treatments 
thereof. 

In one embodiment, the rules engine 61 A is capable of processing rules associated 
25 with assessing bodily injury damages claims. A rules engine 61 A, in one embodiment, 
comprises an expert computer system which utilizes and builds a knowledge base 
developed in the form of business rules to assist the user in decision-making. It allows 
insurance companies to capture the knowledge base of their experts by defining business 
rules. Once created, the expertise may be used in processing many transactions, 
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including assessing bodily injury damages claims. The business rules enable claim- 
processing professionals to be assisted by industry experts to evaluate legal, medical, 
insurance conditions before arriving at a valuation of an insurance claim. 

5 In various embodiments, the rules engine 61 A may be implemented and executed 

on various computing platforms such as personal computers and mainframes. The rules 
engine 61 A may comprise a rules engine executable file on these platforms. In various 
embodiments, the rules engine may be accessed through various user interfaces, such as a 
graphical user interface for a rules engine 61 A which is executable on a Microsoft™ 

10 Windows™-based server 70A. In one embodiment, the rules engine 61 A may be 

developed using a commercial rule-based development tool such as PLATINUM Aion™, 
which is available from Computer Associates International, Inc. In one embodiment, the 
rules may be customized to meet the requirements of a particular insurance company. 

15 Business rules, often referred to simply as rules, may include executable computer 

program instructions. The rules include computer commands or logical instructions to 
achieve a certain function. For example, rules may guide an assessment or estimate of 
bodily injury general damages. In one embodiment, a rule may include a premise 
followed by one or more resulting actions. For example, in one embodiment, a business 
20 rule may state “If patient requires hospitalization after emergency care treatment then the 

trauma severity level should be classified as major.” In this case, the premise is “patient 
requires hospitalization after emergency care treatment.” The resulting action is “trauma 
severity level should be classified as major.” In one embodiment, the insurance claim 
processing server 70 A may include several thousand business rules. The rules may be 
25 executed or fired, under the control of the insurance claim processing software, based on 
certain events, user inputs, etc. Only pertinent rules, i.e., a subset of all the available 
rules, are typically selected and executed for processing a specific bodily injury damages 
claim. On execution of the plurality of rules which are applicable to a specific bodily 
injury claim consultation session, the insurance claim processing server software 60A 
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may generate a consultation report which summarizes an assessment and/or estimate of 
the bodily injuries claim. 

The rules may be stored in and retrieved from an insurance database 40A. The 
5 type of information stored and/or retrieved may include, but not be limited to, business 
objects, tables, rules, software source code, executable software, etc. In one embodiment, 
the database may include a relational database. In another embodiment, the database 40 
may include an object-oriented database. 

10 In one embodiment, the insurance claims processing server software 60A may 

include adapter software 62A which may provide access to the rules engine for one or 
more other computer-based applications or subsystems, such as an internet information 
server 64 A. In one embodiment, the adapter software 62A provides an application 
programming interface (API) to the rules engine 61 A. The adapter software 62 A is 
15 discussed in greater detail with reference to Fig. 4 A. 

In one embodiment, the insurance claims processing server software 60A may 
include a web server such as an internet information server (IIS) 64A. As used herein, a 
“web server” includes a system for supplying clients with access to web pages, such as by 
20 sending the pages to clients via an appropriate protocol. In one embodiment, a web 
server may also be operable to generate the web pages dynamically. As used herein, a 
“web page” includes a block of information which is configured to be displayed by a web 
browser 68A. As used herein, a “web browser” or “browser software” includes software 
which is configured to receive and display web pages. Examples of web browsers 
25 include Internet Explorer™ available from Microsoft™ Corporation and Netscape 

Navigator™ available from Netscape Communications Corporation. Typically, a web 
page is configured to be displayed in a single window in a web browser, wherein the 
window may be scrolled to view off-screen elements of the web page. Web pages may 
include various combinations of text, graphics, audio content, video content, and other 
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multimedia content. A web page is often encoded in a language such as HTML 
(HyperText Markup Language). Web pages may be viewed in a browser on the same 
computer system on which the server 64A or web pages reside. Web pages may also be 
transmitted to a client computer system over a network 55A, such as via the HyperText 
5 Transport Protocol (HTTP) 56. Where the network 55A includes the Internet, the web 
pages may be transmitted via standard protocols such as TCP/IP. 

In one embodiment, the internet information server (IIS) 64A may include a 
commercial product such as Microsoft™ Internet Information Server available from 
10 Microsoft™ Corporation. In one embodiment, the server 64 A may include an active 

server pages (ASP) controller 65A which is operable to generate web pages dynamically. 
In other words, the web pages delivered by the internet information server 64A may be 
built in real time by the ASP controller 65A upon a request for a page by a browser 68A. 
Active server pages may include dynamic web pages which are created, for example, by 
15 blending HTML and server-side scripting. Active server pages may be dynamically 
constmcted to include insurance claim assessment questions and other user interface 
elements by starting from a template. 

The web server 64A may be configured to generate a plurality of web pages 
20 comprising the insurance claim assessment questions. The web browser 68A may then 
be configured to display the plurality of web pages comprising the insurance claim 
assessment questions. The web browser 68A may then be configured to receive 
insurance claim assessment data entered by a user in response to the insurance claim 
assessment questions during an insurance claim consultation session and send the 
25 insurance claim assessment data to the web server 64A. In one embodiment, the web 
server 64A is further configured to receive the insurance claim assessment data from the 
web browser 68 A and send the insurance claim assessment data to the rules engine 61 A. 
The rules engine 61 A may be further configured to generate and send the estimate of the 
value of the insurance claim to the web browser 68 A through the web server 64A. The 
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web browser 68A may be further configured to display the estimate of the value of the 
insurance claim received from the rules engine 61 A through the web server 68 A. 

In one embodiment, the web server 64A and web browser 68A may be located on 
5 separate computer systems which are communicatively coupled through a network 5 5 A. 
In another embodiment, the web server 64A and web browser 68A may be located and 
executed on a single computer system. 

HTTP is considered to be a stateless internet access protocol. In other words, 

10 each request from a web browser 68 A to a web server 64 A is essentially a request- 

response interaction. Therefore, when a web browser 68 A requests a web page, for 
example, the web server 64A may complete the interaction between the two by sending 
the page to the browser 68A. However, a consultation session conducted by a user 
through a web browser 68 A which communicates with the rules engine 61 A may include 
15 many successive interactions through the web server 64 A. It would tend to be inefficient 
to start a rules engine executable file for each of the many interactions that may take 
place during a single consultation session. 

Therefore, IIS sessions may be used to maintain resources and state for each of a 
20 plurality of users. Fig. 3bA is an illustration of an insurance claims processing server 
software architecture for multiple clients 68aA, 68bA, 68cA according to one 
embodiment. The first time a user connects to a suitable web site provided by the server 
64A, a rules engine may be executed or started for that particular user and then “held” in 
an IIS session for that user. Fig. 3bA illustrates an example including three browsers 
25 68aA, 68bA, 68cA which correspond to and communicate with respective rules engines 

61aA, 61bA, 61 cA. Each IIS session may include an individual ASP controller 65aA, 
65b A, 65cA. Each rules engine 61aA, 61bA, 61 cA may therefore be linked to its 
corresponding ASP controller 65aA, 65bA, 65cA through individual adapter software 
62 aA, 62bA, 62cA. 
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Fig. 4A is an illustration of adapter software between a rules engine and a web 
server according to one embodiment. The adapter software 62A may include one or 
more components which permit software such as applications or other components to 
5 communicate with the rules engine 61 A. For example, the adapter software may provide 
methods to start and communicate with a rules engine executable file 61 A. 

As used herein, a component is a software object which includes definitions of 
method of communication for that software object. Typically, components are 
10 implemented according to a component architecture specification such as the Component 
Object Model (COM) or Distributed Component Object Model (DCOM) promulgated by 
Microsoft™. The component architecture specification for COM enables applications 
and components which follow the specification to pass data, commands, and other 
information back and forth. A COM interface may be said to “wrap” an object, server, or 
15 other piece of software if that COM interface defines methods of interaction or 
communication with that object, server, or piece of software. 

In one embodiment, the adapter software 62 A may include one or more COM 
components 63bA and a dynamic link library (DLL) 63aA. As used herein, a DLL may 
20 include a library of executable functions or data that can be used by an application such 
as a Microsoft™ Windows™-based application. Typically, a DLL provides one or more 
particular functions, and a program may access those functions by creating either a static 
or dynamic link to the DLL. A static link remains constant during program execution, 
while a dynamic link is created by the program as needed. In one embodiment, the DLL 
25 63aA may provide a lower-level interface to the functions and methods of the rules 

engine 61 A. For example, the DLL 63aA may take advantage of published protocols for 
accessing a rules engine implemented with a commercial system such as PLATINUM 
Aion™. In one embodiment, the DLL 63aA may be provided by the supplier of the 
commercial system for developing a rules engine. 
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The COM component(s) 63bA may then provide a higher-level interface to the 
DLL 63aA, which in turn may provide an interface to the rules engine 61 A. In other 
words, the “business intelligence” may be confined to the rules engine 61 A and DLL 
5 63aA, and the COM component(s) 63bA may expose an interface which permits other 

pieces of software to convert data, requests, and other parameters to function calls 
provided by the DLL 63aA. In one embodiment, the COM component(s) 63bA may 
include methods including, but not limited to, the following: setListParameter, 
setSingleParameter, getNextMessage, lastErrorMessage, sendMessage, terminates ession, 
10 transactMessage, getListParameter, getSingleParameter, startServerSession, and 
startRefsysSession. Appropriate parameters may be defined for each method. 

Fig. 5 A illustrates the transmission of data between a web server and a web 
browser according to one embodiment. Each ASP controller 65A may be a web-specific 
15 COM component or components that may run in a process space associated with the IIS 
64A. These components may be operable to start, stop, and send data 69A (such as 
insurance claim consultation data entered in response to insurance claim consultation 
questions) to the rules engine 61 A. These components may also be operable to receive 
data (such as insurance claim consultation questions and elements of the user interface) 

20 from the rules engine 61 A for inclusion in one or more web pages 67 A. Generally, these 
components are configured to translate data between HTML on the IIS 64A side and the 
interface exposed by COM components 63bA on the other side. These components may 
include functionality such as data validation (e.g., determining if datatypes of entered 
data are valid). The components may also ensure that the state of the interactions or 
25 “conversation” between a rules engine and a browser is preserved, as discussed in greater 
detail with respect to Fig. 4bA and Fig. 9A. 

In one embodiment, the ASP controller 65A may include at least two COM 
components: one which handles interactions between a web browser 68 and the rules 
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engine executable file, and another which handles interactions between the web browser 
68A and a reference system or help system executable file. The reference system 
executable file may provide the user with detailed assistance in conducting an insurance 
claim consultation session. 

5 

In one embodiment, the COM component(s) for accessing the reference system 
may include methods including, but not limited to, the following: addedRefsysID, 
initializeContentsGraphs, startSessionlfNecessary, MemberOftrueHierarchylds, 
lastSearchText, lastSelectedChapterObjectld, terminateSession, getFirstMessage, 

10 pageHasError, getListParameter, chapterWasSelected, writeRefsysContents, 
writeContextContents, writeSearchResults, writeHelpTextAsHTML, 
contextHelpWasSelected, isSessionStarted, searchHitWasSelected, mergeLostBoys, 
searchWasSelected, and iisSessionld. Appropriate parameters may be defined for each 
method. 

15 

In one embodiment, the COM component(s) for accessing the rules engine 61 A 
may include methods including, but not limited to, the following: terminateSession, 
startSessionlfNecessary, writePredisplayHtml, handleExitProcessing, getFirstMessage, 
pageToShow, errorMessage, pageHasError, pageWasPosted, doPageTransaction, 

20 getSingleParameter, getListParameter, getListParameterNoTrim, debuglt, 

formatAdsDate, hasSaveButton, hasBackButton, hasNextButton, hasContentsButton, 
hasCommentsButton, hasUnknownButton, hasReportButton, claimKeyFormat, 
statusMessage, iisSessionld, and isSessionStarted. Appropriate parameters may be 
defined for each method. 

25 

Fig. 6A illustrates an example of a browser-based user interface for the insurance 
claims processing system according to one embodiment. The browser window 100A 
may be displayed in a display device 50bA coupled to a client computer system. 
Typically, a web browser includes a set of standard navigation commands. As shown in 
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Fig. 6A, examples of these commands may include “back” 1 10A to move to the 
previously visited page, “forward” 1 12A to move to the page previously visited before 
selecting “back,” “reload” 1 14A to obtain and redisplay the current page from the server, 
and “home” 1 1 6A to move to a previously designated home page. These standard 
5 navigation commands may be made available to the user as menu items and/or as buttons 
or other GUI elements. A button may be “pushed,” often by a mouse click or appropriate 
keyboard key, to initiate the command supplied by the button. 

The browser page 104A may include an active server page or other HTML- 
10 encoded page supplied by the web server 64A. The page 104 A may include one or more 
specialized navigation commands. In one embodiment, these specialized navigation 
commands may be displayed as buttons or other GUI elements. In one embodiment, the 
specialized navigation commands may include, for example, “save” 1 20A to save the 
status of a consultation session, “help” 122 A to access a reference system for insurance 
15 claim processing, “exit” 124A to safely exit the insurance claim consultation session, 
“back” 130A to safely move to a previous page of the insurance claim consultation 
session, and “reset” 132A to reset the proper state of the browser page 104A. The reset 
command is further described with reference to Fig. 9A. 

20 Insurance claim assessment data and/or insurance claim assessment questions 

140A may also be displayed in the browser page 104 A. For example, for a given step in 
the insurance claim consultation session, one or more questions may be asked regarding 
bodily injuries and/or treatments thereof. A set of acceptable answers (i.e., insurance 
claim assessment data) may be supplied to the user, such as with a menu or series of 
25 check boxes. The user may then select from the possible answers and enter the insurance 
claim assessment data. The set of acceptable answers may be dynamically generated by 
the rules engine based upon answers to previous questions. 
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Fig. 7 A is a flowchart illustrating a method of developing a web-based insurance 
claims processing system according to one embodiment. The steps shown in Fig. 7A 
may be performed in various orders according to various embodiments. In step 200A, a 
rules engine may be developed or otherwise provided. As discussed with reference to 
5 Fig. 3aA, the rules engine may be configured to estimate a value of an insurance claim as 
a function of insurance claim assessment data entered by a user in response to insurance 
claim assessment questions. 

In step 202A, the rules engine may be wrapped with a component interface in 
10 accordance with a component architecture specification. Component interfaces are 

discussed in greater detail with reference to Figs. 4A and 5A. The component interface 
may include one or more definitions of methods of communication or other access to the 
rules engine, such as by a web server. The component architecture specification may 
include a Component Object Model (COM) specification. 

15 

In step 204A, a web server may be provided, wherein the web server is configured 
to generate a plurality of web pages which are viewable by a web browser. The methods 
of communication in the component interfaces may be operable to transmit the insurance 
claim assessment data from the web server to the rules engine and operable to transmit 
20 the insurance claim assessment questions from the rules engine to the web server. 

Fig. 8 A is a flowchart illustrating a method of hosting a web-based insurance 
claims processing server with various pricing models according to one embodiment. In 
step 250A, an insurance claim processing server may be hosted. As used herein, 

25 “hosting” may include installing, maintaining, and/or otherwise providing client access to 
a server. The insurance claim processing server may be configured to estimate a value of 
an insurance claim as a function of insurance claim assessment data entered by a user 
during an insurance claim consultation session. In one embodiment, the insurance claim 
processing server may include a rules engine and a web server, and the client software 
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may include a web browser. The web server may be operable to generate web pages and 
receive responses and requests from the web browser to enable communication between 
the rules engine and the web browser. 

5 In step 252 A, client software such as a web browser may be provided to a user 

such as an insurance company. In one embodiment, the client software may include 
commercial, off-the-shelf web browser software which may already be in use by an 
insurance company and its employees who seek to access the insurance claim processing 
server. The client software may be operable to receive the insurance claim assessment 
10 data entered by the user and send the insurance claim assessment data across a network to 
the insurance claim processing server. The insurance claim processing server may be 
operable to send the estimate of the value of the insurance claim to the client software 
across the network. In one embodiment, the network may include the Internet. 

15 In step 254 A, the user may be charged for access to the insurance claim 

processing server through client software according to a pricing model. Various pricing 
models may be used with various embodiments of the hosting system and method. The 
pricing model may include a fee for each of a plurality of insurance claim consultation 
sessions conducted by the user. The pricing model may include a fee for each fixed 
20 period of access time of access by the user to the insurance claim processing server 

through the client software. For example, the fixed period of access time may include an 
hourly multiple, a weekly multiple, a monthly multiple, a yearly multiple, or a multiple of 
minutes. The pricing model may include a fee which varies directly with an amount of 
time spent accessing the insurance claim consultation session through the client software. 
25 

The user may include an insurance organization having a particular size, and the 
pricing model varies according to the size of the user. The size of the user may include a 
function of a quantity of employees of the user, a function of revenue of the user over a 
period of time, and/or a function of a quantity of consultation sessions conducted by the 
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user over a period of time. The pricing model may include a pricing discount given to the 
user after a particular quantity of insurance claim consultation sessions conducted by the 
user in a particular period of time. The insurance claim consultation session may include 
one or more insurance claim consultation transactions, and the pricing model may include 
5 a fee for each of a plurality of insurance claim consultation transactions conducted by the 
user during one or more insurance claim consultation sessions. 

The method may further include charging additional users for access to the 
insurance claim processing server through client software according to a same or 
10 different pricing model. 

Fig. 9A is a flowchart illustrating a method of using a reset button provided by a 
web-based interface to a web-based insurance claims processing server according to one 
embodiment. In step 302A, a first page of insurance claim assessment data may be 
15 displayed in a browser program executing on a computer system. The browser program 
may include a web browser program which is operable to read and display web pages. 

The computer system which executes the browser program may include a client computer 
system which is communicatively coupled to a server computer system. The server 
computer system may be operable to generate and send a plurality of pages of insurance 
20 claim assessment data to the client computer system. 

In one embodiment, in step 304A, one of the specialized navigation commands, 
such as a forward command, may be selected to advance to a second page of insurance 
claim assessment data. In another embodiment, the user may advance to the second page 
25 by hitting “return” or otherwise instructing the insurance claim processing server to 

provide a next page in a consultation session. In step 306A, the second page of insurance 
claim assessment data, including the specialized navigation commands, may be displayed 
in the browser. 
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In step 308A, after the second page of insurance claim assessment data is 
displayed, one of the standard navigation commands, such as the “back” command or 
button available in a toolbar or menu in a web browser, may be selected to move back to 
the first page of insurance claim assessment data. The first page of insurance claim 
5 assessment data may then be redisplayed. 

In step 3 1 OA, the user may attempt to perform an insurance claim assessment task 
on the redisplayed first page of insurance claim assessment data. For example, the user 
may attempt to save a status of an insurance claim consultation by pressing a “save” 

10 button in the specialized buttons. The insurance claim consultation may include an 
interactive determination of an estimate of a value of an insurance claim through the 
entry of insurance claim assessment data in response to insurance claim assessment 
questions. The insurance claim assessment task may include selecting one of the other 
specialized navigation buttons provided as the user interface by insurance claim 
15 processing server. The insurance claim assessment task may also include entering new or 
modifying existing insurance claim assessment data. Insurance claim assessment data 
may include information relevant to an estimate of a value of an insurance claim, such as 
bodily injuries and treatments thereof. The insurance claim assessment data may include 
bodily injury claim assessment data, and the insurance claim assessment task may include 
20 a bodily injury claim assessment task. 

In one embodiment, the state of the “conversation” between the browser and the 
insurance claim processing server may be preserved by a COM component 66A, as 
discussed with reference to Fig. 5 A. In step 312A, therefore, a navigation error may be 
25 generated as a result of the attempting to perform an insurance claim assessment task on 
the first page, when the second page is the “correct” page in the conversation. In one 
embodiment, a navigation error message may be generated and displayed to the user as a 
result of the generating the navigation error. The navigation error message may include 
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an instruction to select a reset command, wherein the reset command is one of the 
specialized navigation commands. 

In step 314A, the user may select the reset command after viewing the navigation 
5 error message. In one embodiment, the insurance claim processing server may 
automatically perform a reset function without user intervention as a result of the 
navigation error. 

In step 3 16A, the second page (i.e., the “correct” page) of insurance claim 
10 assessment data may then be redisplayed. The user may then perform a second insurance 
claim assessment task on the redisplayed second page of insurance claim assessment 
data. 

Fig. 2B is a flow chart illustrating the generation of a table of contents for 
15 processing an insurance claim according to one embodiment. In step 100B, the user of an 
insurance claims processing system 10 may use a client system 80 to initially configure, 
or set up, all the display screens associated with the insurance claims processing business 
process. A display screen may be associated with a step included in processing insurance 
claims. In one embodiment, the business process for processing the insurance claims 
20 may utilize an applicable subset of all display screens. The inclusion or exclusion of a 
display screen in a table of contents display screen may be based on business rules, user 
inputs, etc. In another embodiment, the business process for processing the insurance 
claims may utilize all display screens. 

25 In one embodiment, the configuration of each of the display screens involves 

defining the properties of the display screen object such as previous display screen 
pointer, next display screen pointer, source for data displayed, etc. Additionally, each 
display screen configuration may require specifying one or more user input fields, 
defining business rules associated with the processing of data for the display screen, etc. 
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The configuration of the display screen object may include invocation of methods such as 
LoadjScreen, Display_Screen, Validate_Screen, SavejScreen, Process_Screen, etc. In 
one embodiment, a registry is maintained for all display screen objects. Figs. 6B and 6Ba 
show a few examples of the properties and methods associated with a display screen 
5 object according to two different embodiments. 

In one embodiment, the table of contents (TOC) is a display screen, window, or 
subset of a screen which shows a roadmap, including one or more applicable steps, for 
processing an insurance claim. Figs. 5B and 5Ba depict alternate embodiments of a TOC 
10 display screen. The table of contents may include one or more steps required to process 
insurance claims. Each step has an associated display screen. The table of contents 
display screen and each step display screen may be configured as an object. The number 
of steps included in the table of contents may be dynamically and automatically modified 
in real-time based on business rules, user inputs, etc. The display screen object for the 
15 table of contents includes one or more display screen objects, representing intermediary 
steps, selected from all display screen objects. Each display screen object may include a 
property, such as Display ln TOC, which enables the display screen object and 
corresponding step to be included in the TOC. 

20 In step 1 10B, the user of the insurance claims processing system 10 may initiate 

the insurance claim processing by specifying a claim number. The claim number may 
then be received by the insurance claim processing system 10. In step 120B, a 
determination may be made as to whether the specified claim number exists in the 
insurance claims processing system 10, such as in the insurance database 40. If it is 
25 determined that the specified claim number is a new claim number, then program control 
is passed on to step 130B. If a matching record is found in the insurance database 40 for 
the specified claim number, then program control is passed on to step 150B. 

In step 130B, the IC user may set up the claim definition data for a new claim. 
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The setting up of the claim definition data may include providing user inputs through one 
or more display screens, as defined in the registry for the claim definition data display 
screen object. Examples of claim definition data provided by the IC user may include, 
but are not limited to, claimant demographic data such as name, age, address, phone 
5 number, etc., injury code information such as neck, spine, arm, etc., and treatment code 
information such as emergency care, hospital, outpatient, physical therapy, etc. As the IC 
user steps through one or more display screens to enter claim definition data, the 
insurance claim processing software 60 may dynamically modify the properties of the 
display screen objects by using appropriate methods. For example, as an IC user enters 
10 and injury code for a neck injury, all relevant and associated display screens will be 
automatically displayed by using the registry for the display screen object and specific 
properties such as next display screen and previous display screen of the display screen 
object. On completing the entry of the relevant inputs associated with the definition of 
the claim, the IC user may submit a request to display the table of contents screen. 

15 

If the claim number is found in step 120B, the insurance claim processing 
software will generate a request to display the table of contents screen in step MOB. 

When the IC user has entered the claim definition data for a new claim number in step 
130B, a request may be made to display the table of contents screen in step MOB. In step 
20 150B, in response to a request to display the table of contents (TOC) display screen, the 

insurance claim processing software executes a function or method to generate the TOC 
display screen. In one embodiment, executing the function to generate the table of 
contents may include invoking a CreateTOCEntry method for the TOC display screen 
object. Fig. 3B describes in further detail a flowchart for a function or method to 
25 generate the table of contents. In step 160B, the newly generated TOC display is sent to 
the display screen 50 for display to the IC user. 

Fig. 3B illustrates one embodiment of a program or method to build a table of 
contents display. In step 152B, the insurance claim processing software, in one 
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embodiment, executes a Create_TOC_Entry method for all display screen objects which 
have a “True” entry in a Display_In_TOC property field. 

In step 154B, the insurance claim processing software 60 verifies that each 
5 display screen object has been validated, such as by checking that a Valid Screen method 
has been invoked successfully. In one embodiment, the Function Re_Evaluate_All is 
called prior to displaying the TOC and it validates all pages. This validation process may 
choose to remove screens from the process because they are no longer appropriate. 

10 In step 1 56B, a determination is made as to whether the previous screen pointer 

for the current display screen object is present or is not present. If no previous screen 
pointer is present, then that display screen object is included in the TOC display screen. 

In step 158B, if a previous screen pointer is present and if the source of data 
15 property field indicates that the data was entered by a user, then the display screen object 
is included in the TOC display screen. 

In step 159B, the list of display screen objects included with the TOC is returned 
to the calling function. In one embodiment, the screens are then displayed based on 
20 individual logic in their Create TOC Entry function. In many cases, this is default 
behavior. But, in some cases, such as "Conditional Pages," their Create_TOC_Entry 
logic may choose not to show them because their conditions are not met. 

Fig. 4B is a flowchart which further illustrates the use of a table of contents for 
25 processing an insurance claim according to one embodiment. In step 500B, the 

processing of the insurance claim may be initiated by initiating a first step, wherein the 
processing of the insurance claim includes a plurality of steps. The steps may include 
screens displayed on the display device 50 coupled to a computer system 10. The 
insurance claim may include a bodily injury claim, and processing the insurance claim to 
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estimate the value of the insurance claim may include processing the bodily injury claim 
to estimate a bodily injury general damages value. The steps may include steps for entry 
of information relevant to the estimate of the value of the insurance claim. The 
information may include, for example, bodily injury treatment information and/or bodily 
5 injury damages information. 

In one embodiment, for example, the first step may include the user entering a 
claim identification number as discussed with reference to Fig. 2B. In another 
embodiment, entering the claim identification number may already have taken place, and 
10 the “first step” may actually include a step such as the entry of an injury code or 
treatment code during the consultation session. 

In step 51 OB, one or more of the steps in the processing of the insurance claim 
may be proceeded through to arrive at an intermediary step. For example, the user may 
15 enter injury and/or treatment data in response to questions presented in one or more steps. 
In step 520B, the intermediary step may then be displayed. As used herein, the 
intermediary step is any step between the first and final steps in the plurality of steps of 
processing the insurance claim. Proceeding through one or more of the steps in the 
processing of the insurance claim may include entering information relevant to the 
20 estimate of the value of the insurance claim in the one or more of the steps. In step 530B, 

the entered information may be stored in a memory. 

In step 540B, a table of contents may be displayed upon the entry of an 
appropriate command by the user. For example, the user may select a GUI element such 
25 as a button or hit a designated keyboard key to display the table of contents. The table of 
contents may be generated according to the method discussed with reference to Fig. 3B. 
The table of contents may include an ordered list of the steps associated with the 
processing of the insurance claim, and the ordered list of steps may include the first step, 
the intermediary step, and any steps in between the first step and the intermediary step. 
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Therefore, the table of contents may essentially show a “roadmap” of the business 
process for processing insurance claims. The ordered list of steps may be dynamically 
modifiable in response to the entry of information in a step. In other words, steps may be 
added to or deleted from said dynamically modifiable ordered list of steps in response to 
5 the entry of information. In various embodiments, the table of contents may be shown as 
a display screen, window, or other subset of a screen. 

In step 550B, the user may be permitted to select one of the steps from the 
ordered list of steps associated with the processing of the insurance claim in the table of 
10 contents. In step 560B, the selected step may then be displayed in response to the user 
selecting the selected step in the table of contents. In step 570B, in one embodiment, the 
entered information in the selected step may be modified and stored after selecting the 
step in the table of contents. 

15 After displaying the selected step, the intermediary step may be redisplayed upon 

entry of an appropriate command by the user. In one embodiment, in other words, the 
user may go back to the previously displayed step, either through the table of contents or 
through entry of a suitable “back” command. The processing of the insurance claim may 
be continued after redisplaying the intermediary step by permitting the user to enter 
20 additional information relevant to the estimate of the value of the insurance claim. 

The ordered list of steps in the table of contents may include a final step. In one 
embodiment, the final step may be selected at any time from the table of contents. The 
final step may include a consultation report concerning an estimate of the value of the 
25 insurance claim. The consultation report may include information related to the estimate 
of the value of the insurance claim, wherein the estimate may be calculated based on 
information entered in the first step and in any steps in between the first step and the 
intermediary step. 
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In one embodiment, all or substantially all of the steps associated with using the 
table of contents may be executed within a single session of an application program 
executing on a computer system. Therefore, the user of the system need not exit the 
system and restart from the beginning in order to go back to a previously encountered 
5 step. 

Figs. 5B and 5Ba depict screen shots which illustrate an example of a table of 
contents display screen according to two embodiments. 

10 Fig. 6B and 6Ba illustrate exemplary properties and methods associated with a 

display screen object according to two embodiments. 

Fig. 2C is a flowchart illustrating a method for identifying one or more 
contributing factors relevant to an estimate of a value of an insurance claim according to 
15 one embodiment. In step 100C, the user of an insurance claims processing system 10 
may use a client system 80 to initially configure, define, set up the insurance claim 
processing system 10. This includes installing and executing the insurance claim 
processing software or program 60 as well as the insurance database 40. The insurance 
database 40 may include data for various insurance codes related to injuries and/or 
20 treatments. In one embodiment, insurance codes may include injury codes and treatment 
codes. 

In step 1 10C, one or more insurance codes which are relevant to the value of the 
insurance claim may be specified in an insurance claims processing program executable 
25 on a computer system. Each insurance code may be considered a contributing factor to 
the estimated value of the insurance claim. These insurance codes may be entered by a 
user during a consultation session in which a claimant reports his or her injuries and/or 
treatments for a particular insurance claim. In specifying the one or more insurance 
codes, a claim number for the insurance claim may be specified, and the one or more 
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insurance codes may be associated with the claim number. The insurance codes may 
include one or more injury codes, wherein each injury code specifies a bodily injury 
incurred by the claimant. The insurance codes may include one or more treatment codes, 
wherein each treatment code specifies a treatment for at least one of the bodily injuries 
5 incurred by the claimant. 

A consultation report typically includes an estimated value or range of estimated 
values for each bodily injury claim. In determining the range of fair estimate value, the 
insurance claims processing system typically uses contributing factor values, along with 
10 regional factors such as cost of living, etc. to arrive at a monetary estimate. Contributing 
factor values due to bodily injury, in one embodiment, are generally directly proportional 
to the level of trauma experienced during and after the bodily injury. The insurance 
claims processing system may be operable to calculate a numeric value for an insurance 
code wherein, for example, the claimant is in a coma and is on life support system 
15 because of a bodily injury. Treatment received for the bodily injury, such as 

hospitalization, surgery, physical therapy, etc. may contribute to decrease the trauma and 
hence may result in a decrease of the estimated value. In one embodiment, the 
contributing factors associated with the treatment code may therefore have a negative 
value. 

20 

In step 120C, one or more contributing factor values may be determined. Each of 
the contributing factor values corresponds to one of the insurance codes, and each of the 
contributing factor values measures an estimated impact of the corresponding insurance 
code on the value of the insurance claim. The insurance claim may include a bodily 
25 injury claim, and the contributing factor values may be relevant to an estimate of a bodily 
injury general damages value of the bodily injury claim. Each of the one or more 
contributing factor values may include a numeric value. In one embodiment, determining 
the one or more contributing factor values may include calculating the one or more 
contributing factor values as a function of one or more business rules. In other words, a 
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rules engine or other expert system may be configured to calculate dynamically the 
amount that each insurance code adds to or subtracts from the estimate of the value of the 
insurance claim. This amount contributed by one insurance code may be dependent on 
the amounts contributed by other specified insurance codes. In one embodiment, the 
5 expert system may be developed using the PLATINUM Aion™ rule-based development 
environment available from Computer Associates International, Inc. In one embodiment, 
this determination of the contributing factor values may take place after substantially all 
of the insurance codes have been entered and when a consultation report is desired to be 
displayed. 

10 

In step 130C, each of the one or more insurance codes and the corresponding 
contributing factor values may be stored in a table. An example of such a table is 
illustrated in Fig. 3C. Fig. 3C shows a table with a column for the insurance codes (e.g., 
injury codes and treatment codes) 330C and a column for contributing factor values 350. 
15 The values shown are for purposes of example only and are not intended to be limiting. 
The table may include one or more rows, wherein each row of the table includes one of 
the insurance codes and the corresponding contributing factor value. In one embodiment, 
the table may be implemented as a table in a relational database. In one embodiment, the 
table may be implemented in accordance with object-oriented techniques of software 
20 design. 

In step 140C, the table may be sorted by the contributing factor values to generate 
a sorted table of contributing factor values 350C and corresponding insurance codes 
330C. The table may be sorted by contributing factor value 350C in ascending or 
25 descending order. A set of contributing factors (i.e., insurance codes) from the sorted 
table which meet one or more selection criteria may be identified and reported. The set 
of contributing factors may be included in a consultation report which may be printed 
and/or displayed on a display device. The selection criteria may include a selection of the 
largest positive of the one or more contributing factor values up to a certain quantity, 
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such as five. Therefore, identifying and reporting the set of contributing factors from the 
sorted table may include identifying and reporting a sorted set of the largest contributing 
factor values up to the certain quantity. In one embodiment, each contributing factor 
value in the sorted set of the largest positive contributing factor values adds to the 
5 estimate of the value of the insurance claim. The selection criteria may include the 

largest negative of the one or more contributing factor values up to a certain quantity, 
such as five. Therefore, identifying and reporting the set of contributing factors from the 
sorted table may include identifying and reporting a sorted set of the largest negative 
contributing factor values up to the certain quantity. Each contributing factor value in the 
10 sorted set of the largest negative contributing factor values subtracts from the estimate of 
the value of the insurance claim. 

Fig. 2D illustrates one embodiment of a method to transform formula data to 
formulas for assessing bodily injury damages claims according to one embodiment. In 
15 step 100D, the user or the administrator of the insurance claim processing system 20 
provides a rules engine, which is capable of processing rules and operating on formulas 
associated with assessing bodily injury damages claims. 

Business rules, often referred to simply as rules, may include executable computer 
20 program instructions. The business rules may invoke, operate or execute formulas to 
calculate trauma severity values associated with personal bodily injury claims. In one 
embodiment, the formulas include computer commands or logical instructions to achieve 
a certain mathematical function, e.g., assess trauma severity value for a spinal injury. 

Each formula, in one embodiment, may include a function operating on one or more 
25 inputs to compute one or more outputs. In another embodiment, the formulas may 

include a plurality of functions operating on one or more inputs to compute one or more 
outputs. In one embodiment, the function may be mathematical such as add, subtract, 
divide, etc. In another embodiment, the function may be based on custom algorithms, for 
example an algorithm to calculate phantom pain associated with bodily injuries. In one 
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embodiment, the insurance claim processing system may include several formula types, 
wherein each formula may be specified by a unique function. The formulas may be 
invoked, operated, executed or fired, under the control of the business rules. Only the 
pertinent formulas, e.g., a subset of all the available formulas, are typically selected and 
5 executed for processing a specific bodily injury damages claim. 

In step 1 10D, the user or the administrator of the insurance claim processing 
system 20 provides a database 40, which is external to the rules engine, and is capable of 
storing and/or retrieving information associated with insurance claim processing. As 
10 used herein, the term “external” means that the database is separate from the rules engine. 
The type of information stored and/or retrieved may include, but not be limited to, 
business objects, tables, formulas, software source code, executable software, etc. In one 
embodiment, the database may be relational. In another embodiment, the database 40 
may be an object-oriented database. 

15 

In one embodiment, the database 40 may include a plurality of tables, which may 
be accessed by a translator program, also referred to as an application program, to 
transform, create, generate, or instantiate the data stored in the tables into formulas. In 
one embodiment, the database may include a plurality of knowledge bases often storing 
20 knowledge data in the form of tables. Knowledge-bases may include, but not be limited 

to, data, tables, program instructions, business rules, objects, etc. The data stored in the 
knowledge bases may also be in the form of objects. In another embodiment, the 
translator program may transform data stored in tables into static instances of an object 
class. In one embodiment, for example, the formula data table shown by way of example 
25 in Fig. 3D includes data structured in a tabular format, i.e., a table with several rows and 
columns. In one embodiment, the Formulas class of objects may include static instances 
wherein each static instance is a direct representation of a row of data in the formula data 
table. Thus, the formula data table may include all the relevant information necessary to 
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transform each row of the formula data table into a static instance of the Formula object 
class. 



In one embodiment, the entire set of business formulas may be grouped or 
5 classified into a plurality of formula types. Each formula may have a common 

construction style, e.g., a function operating on one or more inputs to compute one or 
more outputs. In one embodiment, there may be several hundred pre-defmed formula 
types. New formula types to meet user requirement may also be created and added to the 
existing formula type list or table. Data included in the example formulas data table 
10 shown in Fig. 3D may typically include information necessary to create a static instance 
of the Formula object class. The formula data may include a plurality of entries in a table 
in a database, and the formula data may include a formula identifier 300D, a sequence 
number 3 10D, a section description, a page identifier, a prompt identifier, an answer 
identifier, a mathematical function or operation 320D, a numeric value 330D, and other 
15 suitable elements. 

In step 130D, the translator program initiates the transformation of data stored in 
the formula data table to formulas i.e. the creation of static instances of the Formula 
object class, by reading the formula data. In one embodiment, methods such as KBOpen 
20 and ControlLoad may be used to open and load the formulas data table. Every 

knowledge base table has a corresponding object class name in the insurance claim- 
processing program 60. For example, the formula data knowledge base table may have a 
corresponding formula object class. The contents of each row are read one row at a time. 

25 In step HOD, data entry in each column of the formulas data table is used to 

transform, or create an instance of the formula class object in the formulas knowledge 
base. The ControlLoad function determines which set of instances of the Formula class 
must first be deleted using Deletelnstances (‘Formulas’) and recreated via 
Class(Formulas).Load function. 
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Once created, the instance of the formulas class in the formulas knowledge-base 
may be invoked, operated, or executed by the business rules by using the calculate 
method with FormulalD and the sequence number as the parameters. In one 
5 embodiment, the calculate method gathers all of the static instances with a specified 
FormulalD along with a sequence number. The calculate method then interprets the 
operations and controls how the formula is executed. The resulting output value is used 
to calculate the trauma severity value. 

10 Although not explicitly shown, Steps 130D and MOD may be repeated, in one 

embodiment, to read all rows of the formulas data table and transform the data to as many 
instances of the formulas class. On invocation or execution of the static instance, the 
insurance claim processing software 60 may compute a trauma severity value applicable 
to a specific bodily injury claim consultation transaction, and print a consultation report, 

15 which summarizes an assessment or estimate of the bodily injury general damages claim. 

In one embodiment, the task of updating, modifying, or revising the formulas may 
be simplified. To update a formula, the user or the administrator of the insurance claim 
processing system 20 may update the data entries stored in the formulas data table. By 
20 executing steps 130D and MOD, the instances of the formulas class may be automatically 
updated to reflect the changes. 

In another embodiment, the task of customizing of formulas to meet specific 
user requirements may also be simplified. The customizing of formula data in response 
25 to business requirements results in customized formulas. To add a new formula type, the 
user or the administrator of the insurance claim processing system 20 may add a new 
instance of the formulas class and update the database 40. By executing steps 130D and 
MOD, the formulas may be automatically customized to reflect the new changes. 
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Fig. 3D illustrate the tabular structure of the formula data table according to one 
embodiment. For purposes of example, four columns are illustrated for the table. In one 
embodiment, the table may comprise fewer or more columns. In one embodiment, the 
formula data table may be implemented in any number of ways, such as a relational 
5 database, in a variety of commercially available database management systems. The 
formula data table may have as many rows as may be supported by the database 
management system in which it is implemented. The formula data table may be accessed 
(e.g., searched, written to, read from, etc.) through a programming interface or standard 
access mechanism (e.g., SQL) which is supported by the database management system in 
10 which the formula data table is implemented. 

Fig. 2E illustrates one embodiment of a method to transform rules data to rules for 
assessing bodily injury damages claims according to one embodiment. In step 100E, the 
user or the administrator of the insurance claim processing system 20 provides a rules 
15 engine, which is capable of processing rules associated with assessing bodily injury 
damages claims. The rules engine may be included as part of the insurance claims 
processing system 10, such as the insurance claims processing program 60, as shown in 
Fig. la. 

20 In step 1 10E, the user or the administrator of the insurance claim processing 

system 20 provides a database 40, which is external to the rules engine, and is capable of 
storing and/or retrieving information associated with insurance claim processing. The 
type of information stored and/or retrieved may include, but not be limited to, business 
objects, tables, rules, software source code, executable software, etc. In one embodiment, 
25 the database may be relational. In another embodiment, the database 40 may be an 
object-oriented database. 

In one embodiment, the database 40 may include a plurality of tables, often 
referred to as knowledge-bases, which may be accessed by a translator program or other 
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application program to transform, create or generate the data stored in the tables into 
rules. In another embodiment, the application program may transform data stored in 
tables into static instances of an object class. In one embodiment, for example, the rules 
data table as shown by way of example in Fig. 3aE includes data structured in a tabular 
5 format, i.e., a table with several rows and columns. The rules data table includes all the 
relevant information necessary to transform each row of the rules data table into an 
equivalent business rule. 

The entire set of business rules may be grouped or classified into a plurality of 
10 rule styles. Each rule style may have a common construction style, i.e., the syntax for the 
rule premise and the resulting rule action may be common. In one embodiment, there 
may be several hundred pre-defined rules styles. New rule styles to meet user 
requirement may also be created and added to the existing rule style list or table. Data 
included in the rules data table shown in Fig. 3aE may typically include information 
15 necessary to construct the rule premise and the resulting one or more rule actions. In one 
embodiment, the rules data table shown in Fig. 3aE may include, but not be limited to, 
columns such as an injury code 300E, an adjustment type, an adjustment amount 310E, a 
rule style 330E, a rule name 320E, etc. 

20 Other types of tables stored in the database 40, in one embodiment, may include a 

LineText table as shown by way of example in Fig. 3cE and a Template table as shown 
by way of example in Fig. 3bE. The LineText table may store lines or other elements of 
text which may be used to generate the rules. The Template table may include 
information which may be used by the application program to read each row of data from 
25 the rules data table and transform, create or generate the rules data into a rule. In one 
embodiment, every rule style may have an entry in the Template table. The location to 
store the transformed rule, the name of the rules data table, the name of the rule style, an 
identifier for the line text, etc. may also be included in the Template table, in one 
embodiment. 
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In step 130E of Fig. 2E, the application program initiates the transformation of 
data stored in the rules data table to rules by reading the rules data. In one embodiment, 
the KBOpen and the ControlLoad methods may be used to open and load the rules data 
5 knowledge base table. In one embodiment, every knowledge base table has a 

corresponding object class name in the insurance claim-processing program 60. The 
contents of each row are read one at a time. 

In step 140E, data entries in each column of the rules data table are used to 
10 transform, create, or construct the rules. Entries for columns like rules style and rules 
name in the rules data table may be used as a key to find a matching record in the 
Template table. Other data stored in the columns of the rules data may be used to build 
the rule premise and/or the resulting one or more rules action. 

15 The specific syntax used to construct the rule is specified in the Template for a 

given rule style 330E and a rule name 320E. For example, in one embodiment, rule style 
RS000 and rule name RN000 may specify: 

IFMATCH Col#l WITH Col#2 = Col#3 THEN Col#4 = Col#5 
where Col#l through Col#5 entries may be read from data stored in columns 1 through 5 
20 of the rules data table shown in Fig. 3aE and where rule style = RS000 and rule name = 
RN000. The text string corresponding to the above transformed rule may be stored in the 
Line Text 370E field of the LineText table shown in Fig. 3cE using LineTextID 360E 
as a location reference obtained from the Template table shown in Fig. 3bE. 

25 Although not explicitly shown, Steps 130E and 140E may be repeated, in one 

embodiment, to read all rows of the rules data knowledge base table and transform the 
data to a plurality of rules. On execution of the plurality of rules, applicable to a specific 
bodily injury claim consultation transaction, the insurance claim processing software 60 
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may print a consultation report, which summarizes an assessment for the bodily injuries 
claim. 



In one embodiment, the task of updating, modifying or revising of rules may be 
5 simplified. To update a business rule, the user or the administrator of the insurance claim 
processing system 20 may update the data entries stored in the rules data table. By 
executing steps 130E and HOE, the rules may be automatically updated to reflect the 
changes. 

10 In another embodiment, the task of customizing of rules to meet specific user 

requirements may also be simplified. To add a new business rule or structurally modify 
an existing rule, the user or the administrator of the insurance claim processing system 20 
may add a new entry to the rule style and rule name table and update the database 40. By 
executing steps 130E and HOE, the rules may be automatically customized to reflect the 
15 new changes. 

Figs. 3aE, 3bE and 3cE illustrate the tabular structure of the Rules data Table, 
Template Table and Line Text Table according to one embodiment. Only four columns 
are illustrated for each of the tables. In one embodiment, each of the tables may comprise 
20 more or fewer columns. In one embodiment, the tables may be implemented in any 
number of ways, such as a relational database, in a variety of commercially available 
database management systems. The tables may have as many rows as may be supported 
by the database management system in which they are implemented. The tables may be 
accessed (e.g., searched, written to, read from, etc.) through a programming interface or 
25 standard access mechanism (e.g., SQL) which is supported by the database management 
system in which the tables are implemented. The data shown in the various tables in 
Figs. 3aE, 3bE, and 3cE are for purposes of example only and are not intended to be 
limiting. 
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In Fig. 4E, an embodiment of the transformation of rules data to rules may include 
a knowledge table 400E. In one embodiment, the knowledge table may be a rules data 
table as shown in Fig. 3aE. In one embodiment, the knowledge table 400E includes data 
necessary to transform, build, create, define, or generate rules based on a specified rule 
5 structure. The transformation method 420E (as discussed in greater detail with reference 
to Fig. 2E) orchestrates the combining of the data from the knowledge table 400E and the 
rule syntax specified in the Template table 440E. The transformation method 420E may 
save the rule as text in an associated knowledge base or insurance database. 

10 Fig. 2F is a flowchart illustrating the generation of a message for processing an 

insurance claim by an insurance claim processing system, according to one embodiment. 
In step 10GF, the user of insurance claims processing system 10 may use a client system 
80 to initially configure, set up, install and store the software associated with the 
insurance claims processing system, including all the messages. 

15 

In one embodiment, a message may be defined by a message code and a 
corresponding message text and both the message code as well as the message text stored 
in a message table. In another embodiment, as shown in Fig. 4F, the message code may 
further include a message section 300F and a message code identifier 31 OF. The 
20 combination of a specific message section and a specific message code identifier 
uniquely specifies or selects the message text 320F from the message table. 

The initial configuration may include specifying or selecting a country and/or a 
language for the installation. In one embodiment, the selection of a language and/or a 
25 country may automatically select a corresponding message text stored in a database. In 
another embodiment, the user may modify the message text during the installation 
process. 

In step 1 10F, the application program software executing in the insurance claims 
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processing system 10 may initiate a request to display a message. This may be in 
response to the execution of code in another portion of the application program software, 
in response to a previous user input and/or in response to the execution of a business rule. 

5 In step 120F, the request to retrieve message text is processed further. In one 

embodiment, the request may be further processed by another portion of the application 
program software by invoking the GetMessageText method of the Message object, and 
including values for MsgSectionln and MsgCodeln arguments associated with the 
GetMessageText method. In another embodiment, the processing of the request may 
10 include executing software of a subroutine function to retrieve a corresponding message 
text for a given message code passed along by the requesting program as an input. The 
message text may be retrieved from a database, in one embodiment or from an object 
repository in another embodiment. 

15 In step 130F, the message text corresponding to a specified message code is 

received from step 120F. In step 140F, the requested message text is sent to the 
requesting program for display. 

Fig. 3F is a flowchart illustrating a method of using a messages table associated 
20 with processing an insurance claim according to one embodiment. In step 200F, an 
insurance claims processing program may generate a request to display a message, 
wherein the request may include a requested message code. Each message code may 
include a sequence of alphanumeric values, wherein each sequence is unique relative to 
the other sequences. In one embodiment, each message code may include a message 
25 section and a message code identifier, as further illustrated in Fig. 4F. 

In step 21 OF, a messages table in a database may be searched for a matching entry 
which matches the requested message code. The table may store a plurality of entries 
including the matching entry, wherein each entry in the table may include a message code 
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and a corresponding message text. The database may be implemented, for example, as a 
relational database or an object-oriented database. 



In step 220F, the matching entry may be retrieved from the table in response to 
5 said searching the table for the matching entry which matches the requested message 
code, wherein the matching entry comprises a matching message text. 

In step 23 OF, the matching message text corresponding to the requested message 
code may be displayed by the insurance claims processing program on a display device 
10 coupled to a computer system. The message text may be configured to assist a user in 
processing an insurance claim using the insurance claims processing program. 

In various embodiments, the message text of each entry in the table may be 
specified during an installation of the insurance claims processing program on a computer 
15 system and/or during an installation of the table on a computer system. The message text 
of each entry in the table in the database may be updated by re-installing the table on the 
computer system without re-installing the insurance claims processing program on the 
computer system. The message text of one or more entries in the table may be 
customized for a particular insurance organization during an installation of the insurance 
20 claims processing program on a computer system. Additionally, the message text of one 
or more entries in the table may be localized for use in a particular geographical location. 

In one embodiment, the insurance claim may include a bodily injury claim, and 
processing the insurance claim may include processing the bodily injury claim to estimate 
25 a bodily injury general damages value. The requested message text may include 

information relevant to an estimate of a value of the insurance claim. The requested 
message code may include an injury code which identifies a specific bodily injury, and 
the requested message text may include a name of the specific bodily injury. The 
requested message code may include a treatment code which identifies a specific injury 
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treatment, and the requested message text may include a name of the specific injury 
treatment. 

Fig. 4F is an exemplary diagram of a messages table in a database according to 
5 one embodiment. In one embodiment, the messages table may include columns such as 
message section 300F, message code identifier 31 OF, and message text 320F. In one 
embodiment, the messages table may be implemented in any number of ways, such as a 
relational database, in a variety of commercially available database management systems. 
The messages table may have as many rows as may be supported by the database 
10 management system in which it is implemented. The messages table may be accessed 
(e.g., searched, written to, read from, etc.) through a programming interface or standard 
access mechanism (e.g., SQL) which is supported by the database management system in 
which the messages table is implemented. 

15 In an embodiment, executable program code used to form at least portions of an 

insurance claim processing system may be generated from a plurality of business rule 
components. As used herein, a “business rule component” may refer to a portion of a 
business rule. In general, business rule components may include templates, program 
instructions, variables and/or parameters. The business rule components may be stored in 
20 one or more database tables (such as are described with reference to Figs. 3aE, 3bE, 3cE, 
and 4F). For example, program code defining one or more business rules used in the 
system may be formed from at least two business rule components. Each business rule 
component may be an entry in a database table. In such an embodiment, two or more 
entries in at least one database table may be combined to form source code for the one or 
25 more business rules. The source code may be compiled to form executable code. As 
used herein, “compiling” refers to transforming from source code (e.g., program 
instructions, data, etc. provided by a programmer) into computer-executable code. In 
other embodiments, the source code may include one or more executable script program 
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instructions. As used herein, a “script” refers to a computer-executable program code 
that does not require a compiling step to be executable on a computer system. 



In an embodiment, one or more database tables used to form business rules may 
5 include at least one table having entries that correspond to business rule templates. As 
used herein, a “business rule template” may refer to a business rule component that 
includes business rule structure information. As used herein, “business rule structure 
information” may refer to data specifying a general outline or arrangement of one or 
more business rules. Business rule structure information may include references to one 
10 or more other business rule components. For example, business rule structure 

information may refer one or more program instructions, one or more business rule 
variables, and/or one or more business rule parameters. In embodiments described 
herein, one or more business rule components may be contained in one or more database 
tables. As used herein, a first business rule component may be said to “refer” to a second 
15 business rule component if either the first business rule component or the second business 
rule component may be used to determine (e.g., access, identify, find the value of, etc.) 
the other business rule component. Additionally, a first business rule component may be 
said to “refer” to a second business rule component if either the first business rule 
component or the second business rule component is associated with data (e.g., a 
20 database key) that may be used to determine (e.g., access, identify, find the value of, etc.) 
the other business rule component. 

In an embodiment, one or more database tables used to form business rules may 
include at least one table having entries that correspond to business rule program 
25 instructions (as described with reference to Fig. 3aE). As used herein, a “program 

instruction” may refer to a computer-executable command. As used herein, one or more 
program instructions may be combined to form a “program code.” A business rule 
program instruction may include references to one or more other database table entries. 
For example, a business rule program instruction may refer to one or more other program 
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instructions, one or more business rule variables, and/or one or more business rule 
parameters. 



In an embodiment, one or more database tables used to form business rules may 
5 include at least one table having entries that correspond to business rule variables. As 
used herein, a “business rule variable” may refer to a business rule component that 
represents a variable in the business rule program code. A business rule variable may 
include references to one or more other business rule components. For example, a 
business rule variable may refer to one or more other business rule variables and/or one 
10 or more business rule parameters. 

In an embodiment, one or more database tables used to form business rules may 
include at least one table having entries that correspond to business rule parameters. As 
used herein, a “business rule parameter” may refer to a business rule component that 
15 represents a fixed value in the business rule source code. The value represented by a 
business rule parameter may be specific to a given business rule, business rule variable, 
business rule program instruction and/or business rule template. For example, two or 
more business rules may be formed using the same business rule template, the same 
program instructions, the same business rule variables, and one or more different business 
20 rule parameters. 

In an embodiment, business components may be combined in a transformation 
method, as described with reference to Fig. 2E. In another embodiment, two or more 
business rule components may be combined in a rule editor, generally referenced by 
25 numeral 1200 in Fig. 12. As used herein, a “rule editor” may refer to a computer- 

executable program that combines business rule components to form a graphical display 
of at least a portion of at least one business rule. For example, in the embodiment 
depicted in Fig. 12, rule editor 1200 may combine business rules stored in one or more 
template tables 1202, one or more line text tables 1204, one or more knowledge tables 
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1206 and/or one or more text tables 1208 to form a display of at least a portion of at least 
one business rule. In such an embodiment, template table 1202 may include one or more 
business rule templates. Line text table 1204 may include one or more program 
instructions. Knowledge table 1206 may include one or more values for one or more 
5 business rule parameters. Text table 1208 may include one or more human language 
translations of one or more other business rule components. An advantage of such 
embodiments may be that viewing source code may be simplified as compared to 
embodiments where a user views individual component entries in one or more database 
tables. Fig. 16 depicts an embodiment of a method of generating a graphical display of at 
10 least a portion of at least one business rule in a rule editor. In certain embodiments, rule 
editor 1200 may combine the business rule components and a transformation method 
1210 may compile the source code. Alternately, a transformation method may be 
incorporated into rule editor 1200. 

15 In step 1605 of Fig. 16, at least one first business rule component may be 

accessed. At least one first business rule accessed may include business rule structure 
information. For example, at least one first business rule accessed may include a 
business rale template. At step 1610, a plurality of second business rule components may 
be accessed. For example, the second business rale components may include program 
20 instructions, business rale variables and/or business rale parameters. In certain 

embodiments, the first and/or second business rale components may be stored as entries 
in one or more database tables. At step 1615, a number of the second business rale 
components accessed may be arranged in the graphical display as directed by the 
structure information. For example, if the structure information includes an equation 
25 listing several variables in a given order, the variables may be displayed in the rule editor 
as directed by the equation. In another example, the plurality of second business rale 
components may include two or more program instructions. Step 1615 may include 
arranging the program instructions as specified in the business rale structure information, 
as described with reference to Figs. 3aE, 3bE and 3cE. In certain embodiments, a method 
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of generating a graphical display of at least a portion of at least one business rule in a rule 
editor may also include determining access privileges of the user, as depicted in step 
1620. Based on the user’s access privileges some information may be inhibited from 
being displayed. 

5 

A graphical display of a rule editor may include multiple views of at least a 
portion of at least one business rule. In an embodiment, a plurality of views may be 
displayed as tabs in a display window. For example, an exemplary embodiment of a 
graphical display of a rule editor is depicted in Fig. 13 and generally referenced by 
10 numeral 1300. Each tab of rule editor display 1300 may correspond to a business rule 
component and/or a level of access privileges. In such embodiments, only users having 
appropriate access privileges may view and/or modify information in certain tabs. For 
example, the rule editor may be configured to allow users to view information on all of 
the tabs. However, only users having special access privileges may be permitted to 
15 modify the information. Alternately, a user’s access privileges may also be used to 
inhibit display of certain information or tabs. In another example, users having a first 
level of access privileges may modify business rule parameters in the rule editor, but may 
not change other data. In such cases, users having a second level of access privileges 
may be allowed to modify business rule variables, templates and/or program instructions, 
20 but may not be allowed to modify values of business rule parameters. Users having a 
third level of access privileges may be allowed to modify any business rule component. 

In each of the example cases, modifications to database tables based on user 
modifications in the graphical display may be made immediately or stored in memory 
until approved. 

25 

In an embodiment, a user may access a display of a business rule template by 
selecting Template tab 1306. In such an embodiment, the user may specify a template to 
be displayed by selecting a template from template selection field 1302. The user may 
specify a particular business rule to display by selecting the business rule in business rule 
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field 1304. The specified business rule may be displayed in rule display 1308. Rule 
display 1308 may include a display of a plurality of program instructions (e.g., “program 
instruction 1”, “program instruction 2”, etc.). The program instructions may be arranged 
sequentially in the order of execution of the instructions, as is common to computer 
5 program code. A program instruction may refer to one or more business rule variables 
and/or one or more business rule parameters. For example, program instruction 1 
(referenced by numeral 1310) is depicted as being a function of “variable 1” and 
“parameter 1”. Likewise, program instruction 3 (1318) is depicted a being a function of 
“parameter 2”. In addition, program instruction 4 (1320) is depicted as being a function 
10 of “variable 2” and “parameter 3”. In various embodiments, rule display 1308 under 

template tab 1306 may include data specific to the selected business rule. For example, a 
value of a business rule parameter may be specific to an individual business rule. The 
value of the parameter may be displayed in rule display 1308. In some embodiments, a 
template may be used to form a number of different business rules. In such 
15 embodiments, rule display 1 308 may not include data particular to an individual business 
rule. Rather, rule display 1308 may include information pertaining to all business rules 
formed using the template. For example, an identifying descriptor may be displayed for 
“parameter 1” and/or “variable 1” rather than a particular value. In an embodiment, 
information specific to a selected business rule may be displayed by selecting the 
20 appropriate tab. For example, if the user selects variables tab 1312, variables specific to 
the selected business rule may be filled into the program instructions, as depicted in Fig. 
14. If the user selects parameters tab 1314, parameters specific to the selected business 
rule may also be filled in to the program instructions, as depicted in Fig. 15. 

25 In addition to allowing the user to view business rule source code, rule editor 

1200 may allow the user to modify business rule components. In certain embodiments, 
modifications made in the rule editor may modify one or more database table entries. For 
example, in Fig 14 program instruction 1410 refers to a “variable 1”. The user may 
modify program instruction 1410 in the rule editor to refer to a “variable 2”. In such 
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embodiments, a database table entry corresponding to program instruction 1410 may be 
changed to include a reference to the variable 2. In other embodiments, changes made by 
the user may be stored in a memory without being made to a database table. An 
advantage of such embodiments may be that the changes stored in memory may be 
5 verified and/or approved by another user before changes are made to a database table. In 
certain embodiments, a rule editor may determine a user’s access privileges before or 
during display of a business rule. The user’s access privileges may be used to determine 
portions of the business rule that the user may change. In addition, the user’s access 
privileges may be used to determine whether changes made by the user are made in one 
10 or more database tables or stored in memory for verification by another user. An 

advantage of such embodiments may be that business rules may be modified by users 
without substantial programming experience without fear of contaminating the one or 
more business rule database tables, since experienced programmers may be used to verify 
entries and/or changes. 

15 

Fig. 1 7 depicts an embodiment of a method of modifying a business rule in a rule 
editor. Step 1705 states that a plurality of business rule components may be provided in a 
memory of a computer. For example, business rule components may be provided as 
entries in one or more database tables. The business rule components may include, but 
20 are not limited to: business rule templates, program instructions, business rule variables 
and/or business rule parameters. A plurality of business rule components may be 
combined in a graphical display to form a display of at least a portion of at least one 
business rule in step 1710. At step 1715, input may be received including one or more 
modifications to at least the displayed business rule. For example, the input may be 
25 received from a user or another computer. At least one business rule component may be 
modified in the memory of the computer based on the one or more modifications input at 
step 1720. For example, one or more SQL commands may be generated to modify one or 
more database entries. As used herein, “SQL” is a generic term that refers to a 
programming interface or standard access mechanism usable to access, modify and/or 
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otherwise interact with a database table. The term is not intended to refer exclusively to 
query languages that meet certain established standards for structured query languages. 
Rather, the term is intended to refer broadly to any computer executable method usable to 
access and/or modify database tables. As used herein, an “SQL command” refers to an 
5 individual program instruction that is executable to access, modify and/or otherwise 

interact with a database table. Additionally, in certain embodiments, one or more log file 
entries may be generated and stored in memory, as shown in step 1725 (depicted in 
dotted lines to indicate that this step may not always be present). 

10 In an embodiment, a rule editor display may allow a user to interact with one or 

more database tables directly using SQL commands. For example, by selecting SQL tab 
1328, the user may be presented with an SQL command entry field 1802, as depicted in 
Fig. 18. SQL command entry field 1802 may allow the user to execute a full range of 
SQL commands supported by the database management system in which the database 
15 tables are implemented. Alternately, SQL command entry field 1802 may allow the user 
to execute only a restricted set of SQL commands. In some embodiments, SQL 
commands that may be executed from SQL command field 1802 may be restricted based 
on the access privileges of the user. 

20 In certain embodiments, a method of modifying a business rule in a rule editor 

may include determining what changes a user has input. For example, the user may make 
changes to a business rule in a graphical display of at least a portion of the business rule. 
The rule editor may compare the content of the graphical display to components of the 
business rule stored in memory to determine what changes the user has made. For 
25 example, the rule editor may determine what changes the user has input if one or more 
trigger events occur. Trigger events may include making a new selection (e.g. selecting a 
new business rule component, business rule, tab, etc.). Trigger events may also include 
closing the rule editor, activating a “save changes” feature or another keystroke or mouse 
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movement. Trigger events may also include passing of a determined period of time (e.g., 
5 minutes). 

In an embodiment, a rule editor may provide a user with a listing of business rule 
5 components contained in one or more database tables. In such embodiments, the user 
may select two or more of the business rule components and combine the two or more 
components in the graphical display to form a new business rule. Alternately, the user 
may create one or more new business rule components in the graphical display. For 
example, the user may enter one or more new lines of program instruction. In another 
10 example, a new business rule template may be created by specifying an order of program 
instructions, business rule variables and/or business rule parameters in a business rule. 
The one or more new business rule components may be saved in one or more database 
tables. The one or more new business rule components may be combined with one 
another and/or with previously existing business rule components to form a new business 
15 rule. 

Fig. 19 depicts an exemplary embodiment of a method of creating a new business 
rule in a rule editor. At step 1905, a graphical display may be provided. The graphical 
display may be configured to combine a plurality of business rule components to create a 
20 display of at least a portion of a business rule. At step 1910, business rule structure 

information may be determined. For example, a user may select a predefined business 
rule template. In another example, the user may input (e.g., type) business rule structure 
information into the rule editor. The rule editor may determine structure information 
based on the input received. In yet another embodiment, business rule structure 
25 information may be determined based on other input. For example, a user may select and 
arrange one or more business rule components in the graphical display. Business rule 
structure information may be determined based on the selection and arrangement of the 
business rule components. For example, the user may specify one or more program 
instructions. The user may further specify one or more parameters. The user may 
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specify other information as well, such as, but not limited to one or more business rule 
variables to be included in a specified relationship to one or more program instructions. 
The new business rule may be stored in a memory associated with a computer system at 
step 1920. For example, the business rule structure information may be stored in the 
5 memory with one or more references to business rule program instructions, business rule 
variables, business rule parameters and/or business rule translations. In an embodiment, 
the business rule components may be stored as entries in one or more database tables. In 
embodiments where the business rule structure information and/or program instructions 
have been selected from a list of predefined business rule components, one or more of the 
10 business rule components may be saved as references to the predefined business rule 
component. 

In some embodiments, a rule component may be used by more than one business 
rule. For example, a business rule template may define the structure of a business rule. 

15 The business rule template may be used with different combinations of business rule 
program instructions, business rule variables and/or business rule parameters to form 
different business rules. In another example, a business rule program instruction may be 
used with different combinations of business rule templates, business rule variables 
and/or business rule parameters to form different business rules. In such embodiments, a 
20 rule editor may display a listing of business rules and/or business rule components that 
may be affected by changes to one or more selected business rule components. 

Fig. 21 depicts an embodiment of a method of displaying a listing of business rule 
components related to a selected business rule component. The business rule components 
25 may be related in such a manner that a change made to the selected business rule 

component may affect the listed business rule components. At step 2105, a plurality of 
business rule components may be provided. The business rule components may include 
business mle templates, program instructions, business rule variables and/or business rule 
parameters. A plurality of business rules may be formed by combining a number of the 
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business rule components. At least a portion of at least one business rule may be display 
to a user at step 2110. At least one business rule component may be selected in the 
graphical display in step 2115. One or more business rule components that reference the 
selected business rule component may be determined in step 2120. The one or more 
5 business rule components determined to reference the selected business rule may be 
displayed to the user at step 2125. 

Fig. 22 depicts an embodiment of a method of generating a graphical display 
including at least one business rule template that is related to a selected business rule 
10 component. At step 2205, a plurality of business rule templates may be provided. At 
step 2210, a plurality of business rule components may be provided. A first business rule 
template may be used to generate a graphical display of at least a portion of at least one 
business rule in step 2215. At step 2220, one or more business rule components may be 
selected in the graphical display. One or more second business rule templates that use the 
15 selected business rule component may be determined at step 2225. A graphical display 
that identifies at least one of the second business rule templates may be generated at step 
2230. 

Referring back to Fig. 15, an embodiment of a display screen including a list of 
20 business rule components related to a selected business rule component is depicted. In 
Fig. 15, “template 1” has been selected in template selection field 1302. Additionally, 
“rule 1” has been specified in rule selection field 1304. Thus, the business rule displayed 
in rule display 1308 is business rule #1. Within rule display field 1308, program 
instruction 2 (1502) has been selected as indicated by the dotted line surrounding 
25 program instruction 2. Thus, program instruction 2 is shown to be the selected business 
rule component in selected component field 1504. Linkages field 1506 displays a list of 
all of the business rule templates that use or refer to program instruction 2. 
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In an embodiment, the relationships between various business rule components 
may also be viewed in a database table view. For example, Fig. 20 depicts an 
embodiment of a Tables tab 1326 view. Tables tab 1326 may include table selection field 
2002. Table selection field 2002 may allow a user to specify a database table to be 
5 viewed in display field 2006. Additionally, tables tab 1326 may include a selection 
criteria field 2004. Selection criteria field 2004 may allow the user to specify one or 
more criteria which may be used to constrain the table display. For example, selection 
criteria field 2004 may be used to specify one or more search criteria. In such a case, 
only those database records including specified search criteria may be displayed in 
10 display field 2006. In another example, selection criteria field 2004 may be used to 

specify a sort order in which to display the database table. During use, display field 2006 
may display at least a portion of the contents of a database table. An advantage of 
displaying database table contents to a user may be that viewing the database table 
information without modification by the rule editor may allow for increased flexibility in 
15 troubleshooting. 

In certain embodiments, a rule editor may save at least one log file of changes 
made. In various embodiments, a log file may include but is not limited to a listing or 
description of at least one change made; an identification of a user that made the change; 
20 if appropriate, an identification of a user that verified or approved the change; and a time 

and/or date stamp. 

Fig. 23 depicts an embodiment of a method of tracking changes made to one or 
more business rule components. In step 2305, a plurality of business rule components 
25 may be provided in a memory. At step 2310, a graphical display of at least a portion of at 
least one business rule may be generated by combining a plurality of the provided 
business rule components. The graphical display may be viewed by a user. The user 
may determine one or more changes to be made to at least the displayed business rule. 
Input may be received specifying one or more modifications to at least a portion of at 
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least one business rule at step 2315. A record of one or more modifications input may be 
stored in a log file in a memory at step 2320. In an embodiment, one or more 
modifications may be made to one or more business rule components in memory based 
on the input. Alternately, in some embodiments, the modifications may be stored in 
5 memory pending approval by a user having appropriate access privileges. 

An exemplary embodiment of a rule editor window that includes information 
related to changes made to one or more business rules is depicted in Fig. 24. A user may 
specify a business rule template and/or a business rule using selection fields 1302 and 
10 1304, as previously described. The user may select audit tab 1330 to view log file entries 

related to changes made to the selected business rule template or business rule. For 
example, a log file entry 2404 may include a description of a modification made 2406. 
The description may include a user input description of the modification or a computer 
generated description of the modification. For example, the description may include a 
15 copy of one or more business rule components before the modification and a 

corresponding copy of the one or more business rules including the modification. Log 
file entry 2404 may also include a time and/or date stamp 2408 indicating when the 
modification was input, stored in memory and/or approved. Log file entry 2404 may also 
include an identification of the user that input the modification 2410 and/or a user that 
20 approved the modification 2412. Log file entry 2404 may also include a description of 
the reason a change was made 2414. Additionally, log file entry 2404 may include an 
identification of one or more business rule components changed and/or one or more 
database tables changed. 

25 In certain embodiments, one or more database tables may include at least one 

human language translation of at least one business rule component. As used herein, a 
“human language translation” may refer to an approximate interpretation, explanation, 
and/or paraphrasing into a human language of the purpose, meaning and/or effect of a 
business rule component. For example, the human language may be English. For 
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example, the translation may be a simplified description of the effect of the business rule 
component. In such embodiments, a rule editor may be configured to access at least one 
human language translation of a business rule component. The rule editor may access 
and display at least one human language translation in response to a request by the user. 

5 In some embodiments, the rule editor may be configured to display at least a portion of a 
business rule with one or more human language translations substituted into the business 
rule in place of one or more corresponding business rule components. For example. Fig. 
25 depicts a display screen with text tab 1316 selected. If a user selects text tab 1316 one 
or more business rule components may be replaced by one or more corresponding human 
10 language translations. Thus, lines 2510, 2622, 2518, 2520, and 2524 may be related to 
lines 1310, 1322, 1318, 1320, and 1324 of Fig; 13. For example, line 25 10 may be the 
same as line 1310 except that program instruction 1 and parameter 1 have been replaced 
in the display with human language translations. Similarly, program instruction 2 of line 
1322, program instruction 3 and parameter 2 of line 1318, program instruction 4 and 
15 parameter 3 of line 1320, and program instruction 5 of line 1324 have been replaced by 
human language translations in lines 2522, 2518, 2520, and 2524, respectively. In other 
embodiments, human language translations may be substituted for different business rule 
components. For example, only program instructions may be translated. In another 
example, only business rule parameters may be translated. An advantage of providing at 
20 least one human language translation of a business rule component may be that a user 
may be better able to understand a business rule or business rule component based on a 
human language translation than based on one or more lines of source code. For 
example, such embodiments may be advantageous if users that create, modify and/or 
approve business rules are not experienced programmers. In an embodiment, a plurality 
25 of human language translations of one or more business rule components may be 

provided. An advantage of providing multiple languages may be that two or more users 
that prefer different languages may view, create, modify and/or approve business rules. 
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Fig. 26 depicts an embodiment of a method of providing a graphical display 
including at least one human language translation. At step 2605, a plurality of business 
rule components may be provided. For example, the business rule components may 
include business rule templates, program instructions, business rule variables and/or 
5 business rule parameters. At least one human language translation of at least one 
business rule component may be provided at step 2610. Business rule structure 
information that specifies an arrangement of two or more business rule components to 
form a business rule may be provided at step 2615. For example, a business rule template 
may be provided. The business rule template may include references to two or more 
10 business rule components and an arrangement of the referenced components to form a 
business rule. At step 2620, a graphical display of at least a portion of at least one 
business rule may be generated. The graphical display may include at least one human 
language translation of at least one business rule component. For example, in generating 
the graphical display human language translations of business rule components may be 
1 5 displayed in place of the business mle components. 

In certain embodiments, an insurance claim processing system may include a 
graphical display 2700 for input and display of information as depicted in Figure 27. In 
such embodiments, graphical display 2700 may include a human body representation 
20 2702. For example, human body representation 2702 may include a photograph, graphic 

image and/or a silhouette of a human body. Representation 2702 may depict at least a 
number of major body parts 2704 (e.g., torso, head, arms and legs). In certain 
embodiments, representation 2702 may further include minor body parts/subparts 2706 
(e.g., neck, fingers, toes, etc.) and/or portions of specific anatomical systems (e.g., bones 
25 of the skeletal system as depicted in Figures 30 and 31). Human body representation 
2702 may include a number of different views that may be displayed simultaneously, 
individually or in groups. For example. Figure 27 includes a depiction of a skin layer of 
a male 2708, Figure 28 includes a depiction of a skin layer of a female 2802, Figure 29 
includes a depiction of a muscular layer 2902 and Figure 30 includes a depiction of a 
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skeletal layer 3004. Each view (or layer) may include at least one anatomical system. 
Additionally, individual organs associated with an anatomical system may be depicted. If 
all of the available layers are not depicted simultaneously, the user may be able to select a 
layer to view. For example, a layer selection mechanism 2710 may be provided. 

5 

In an embodiment, a human body representation may provide a user with 
descriptive information about various body parts. For example, referring to Figure 29, 
when the user selects a body part 2904, the graphic display may present information 
describing the body part (e.g., name, major functions, components, etc.) in a description 
10 field 2908. In certain embodiments, insurance related information may be provided in 
description field 2908 or in another description field (e.g., input field 2910) when a body 
part is selected. For example, injuries common to selected body part 2904 may be 
displayed. In such a case, the injury information may include one or more injury codes 
associated with selected body part 2904. In another example, the insurance related 
15 information may include one or more common medical treatments associated with the 
selected body part. An example of a human body representation including a number of 
layers is available from A.D.A.M. Inc. of Atlanta, Georgia. 

In various embodiments, the body part or body parts of interest may be selected 
20 using various selection methods. For example, a “hover” method may allow a user to 
select a body part using a cursor-positioning device. Similarly, a user may position a 
pointer 2906 over a body part of interest using a cursor-positioning device (e.g., a mouse, 
joystick, trackball, etc.) and depress a select button to select a body part. The user may 
also be provided with one or more input fields 2910. In such a case, the user may provide 
25 input via one or more input fields 2910 to select a body part of interest. Additionally, in 
embodiments where the user is provided with one or more input fields 2910, input fields 
2910 may be populated with data as the user makes selections in graphical display 2700. 
For example, if a user selects a fracture to the upper arm in graphical display 2700, one or 
more input fields 2910 may be populated with data reflecting the selected information. 
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Populating the input fields may provide a double check to reduce the likelihood of input 
errors. Additionally, populating the input fields may assist in familiarizing users with 
various insurance related codes (e.g., injury codes, treatment codes, etc.). In any of these 
cases, the selected body part may be highlighted in graphical display 2700. As used 
5 herein, “highlighting” refers to modifying the display to provide a visual indication that 
an area has been selected. For example, highlighting may include, but is not limited to: 
changing the color, changing the brightness, changing the location and/or outlining the 
selected body part. 

10 In an embodiment, upon selection of a body part(s) the user may be provided with 

a menu including one or more input selections related to the selected body part. For 
example, the menu may provide a selection of subparts of the selected body part. A 
“subparf ’ of a body part may refer to a body part or system within the selected body part. 
For example, as depicted in Figure 30, the user may select spine 3002 from a skeletal 
15 layer 3004. Menu 3006 may be changed to include relatively broad selections associated 
with spine 3002, such as central nervous system or spinal column. Alternately, the menu 
may include more detailed selections such as individual bones of the spine, individual 
bones of the skull and/or individual portions of the central nervous system. In another 
example, menu 3006, provided when a body part is selected, may include a selection of 
20 input data related to the selected body part such as common injuries, injury codes, 

common medical treatments and/or treatment codes associated with the selected body 
part. In such a case, the user may select one or more menu selections to provide input to 
the insurance claim processing system regarding injuries suffered and/or treatments 
provided. In an embodiment, a number of menu lists may be presented to the user in 
25 series to allow selection of both a subpart and insurance information (e.g., injury codes, 
treatment codes, etc.). Such menu lists may be arranged to minimize the number of 
menus that a user must go through in order to provide desired input. 
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In an embodiment, additional graphical elements may be provided in graphical 
display 2700 when a body part is selected. For example, when the user selects spine 
3002 (as shown in Figure 30), graphical display 2700 may be changed to show a detailed 
view 3102 of the spine (as depicted in Figure 31). The additional graphical elements may 
5 replace or supplement one or more human body representations in the display screen. In 
certain embodiments, a photograph including a selected body part may be included in the 
graphical display. In certain embodiments, a more detailed graphic depiction of the 
selected body part may be provided. For example, the display may zoom in on the 
selected body part as depicted in Figure 3 1 . Additionally, one or more additional 
10 graphical elements may include alternate views of the selected body part. For example, 
the body part may be rotated in one or more additional graphical elements. If the user has 
provided information identifying an injury or injury code, a graphic element may depict 
an example of the injury. For example, a photograph of a patient having the identified 
injury may be displayed. If the injury is relatively localized, the graphical element 
15 depicting the injury may depict the injury as it may affect the selected body part. 

Similarly, if a treatment is identified and related to a particular body part, a graphical 
element depicting the treatment as it applies to the particular body part may be displayed. 

FIG. 32 illustrates a screenshot of an embodiment for input and display of 
20 information for an insurance claim. In some embodiments, a user may select from a 

displayed listing 3204 of available anatomical systems. For example, a user may select a 
skeletal view 3203 from the list. The user may move a selection indicator, such as a 
mouse pointer, on the screen, or in some other way select an anatomical system. In some 
embodiments, the anatomical system may be selected when a mouse pointer is moved 
25 over an anatomical system name or if the user clicks on the anatomical system name 
(e.g., skeletal view 3203). In some embodiments, the human body representation 3202 
may switch to the selected representation (e.g., a skeletal representation 3202) when the 
user selects the desired anatomical system from the list. 
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A user may select a body part on the human body representation 3202, e.g., by 
moving a mouse pointer on the screen over the body part or moving a mobile highlighted 
region over the body part using arrow keys on a keyboard. Other ways of selecting a 
body part may also be used. In some embodiments, the selected body part may be 
5 distinguished by highlighting (e.g., in yellow) when it is selected. In some embodiments, 
different highlighting colors may be used for different body parts (e.g., subparts of the 
spine may be highlighted in blue). In some embodiments, the selected body part may be 
outlined or circled in addition to or instead of highlighting. 

10 In various embodiments, a name of the selected body part may be displayed in a 

structure name box 3201 . For example, if a user moves a mouse pointer over the ribs on 
the representation 3202, “Ribs” may be displayed in the structure name box 3201. Other 
ways of indicating the body part name may also be used. In addition, other information 
may also be displayed in the structure name box 3201 or displayed in some other way 
15 relative to the body part location. 

In an embodiment, as seen in FIG. 32, a user may select a right shoulder 3205. In 
some embodiments, the user may click on the right shoulder 3205 or move a mouse 
cursor over the right shoulder 3205. In some embodiments, an injury 321 1 for the 
20 selected body part may be entered by the user in an injury text box 32 1 7 or using a menu 
(not shown). In some embodiments, a user may use abbreviations for injuries 3209, as 
listed on a screen, when entering injuries for the selected body part. In some 
embodiments, injuries for body parts in the skeletal representation 3202 may include 
dislocation, disc injury, fracture, fracture/dislocation, and subluxation. In some 
25 embodiments, a part may be selected on the skeletal representation 3202 that does not 
correspond to a bone (e.g., an elbow). In addition, injuries not related to the displayed 
representation may also be entered. For example, injuries, such as a muscle sprain, not 
related to the displayed skeletal representation 3202 may be entered. 
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In some embodiments, if an injury is entered for a body part, the body part may be 
designated as an injured body part. For example, an injured body part may be 
highlighted in red on the skeletal representation 3202. In some embodiments, different 
types of injured body parts may be highlighted in different colors (e.g., injured parts of 
5 the spine may be highlighted in orange). In some embodiments, a user may select which 
colors to use for highlighting different body parts. In some embodiments, different 
degrees of injury may also be designated in different ways. 

In various embodiments, an injury code 3215 may be entered to represent an 
10 injury or information related to an injury for a body part in the representation. In some 
embodiments, the injury code may be automatically displayed based on an entered injury 
without a user having to separately enter the injury code 3215. In some embodiments, a 
check box 3213, or some other indicator, may be provided next to the displayed listing of 
the injury. In some embodiments, the check box 3213 may be used to indicate whether 
15 the injury has been verified. In some embodiments, the check box 3213 may be 
unchecked to remove an injury from consideration in an insurance claim (e.g., in 
calculating damages). In some embodiments, the injury may remain listed (even though 
not considered, i.e., checked) in the insurance claim and may be rechecked to add the 
injury to the claim. For example, if an injury has not been confirmed, the injury may be 
20 entered, unselected, and then selected when confirmed (e.g., by a doctor). In some 
embodiments, the injury may not be checked when the injury is first entered. 

In various embodiments, multiple body parts may be selected in the skeletal 
representation 3202. For example, the hand 3207 may be selected to indicate an injury to 
25 a little finger and the right shoulder 3205 may be selected to indicate an injury for the 

right shoulder 3205. In some embodiments, general notes about a selected body part may 
also be included. For example, a complaint may be entered for a body part (e.g., if pain 
is indicated in a body part, but an injury has not been identified). 
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As seen in FIG. 33, a spine 3301 in the skeletal representation 3202 may be 
selected. In some embodiments, information, including the body part name and 
additional information about the body part, may be displayed relative to the selected body 
part. For example, in some embodiments, the body part name and information may be 
5 displayed in a structure name box 3303. Other locations may also be used. FIG. 34 
shows another example in which a left navicular 3401 and a right femur 3409 has been 
selected. Respective injuries 3405 and 3407 may be entered for the selected navicular 
and femur. In some embodiments, different highlighting or indicators may be used for a 
body part that is currently selected and body parts that have been previously selected and 
10 had a respective injury entered. For example, different color shading, outlining, circling, 
etc. may be used for different types of indicators. 

FIG. 35 illustrates a screen shot of an embodiment for inputting and displaying 
information about a spine. In some embodiments, spine 3509 may be on the listing of 
15 anatomical systems to display. Other body parts may also be put onto the listing. In 

some embodiments, an indicator 3511 may be displayed relative to an anatomical system 
listed to indicate that input information relative to the anatomical system has been 
received. For example, a check mark may be displayed next to “Skeletal” in the listing of 
anatomical systems to indicate that the user has input information relative to skeletal 
20 injuries. 

In some embodiments, a body part of the anatomical system may be selected (e.g., 
by a mouse pointer, etc.) and an input menu may be displayed near the selected body 
part. For example, the T10 vertebrae may be selected and a menu 3507 may be 
25 displayed. In some embodiments, the menu may display body parts and/or subparts 

relative to the selected region. In one embodiment, “T10” 3505 may be displayed as the 
relevant body part highlighted. In some embodiments, a user may want to select a body 
part from the menu and a further listing of relevant injuries (e.g., fracture 3503) may be 
displayed. Other information may be displayed in the menu in place of or in addition to 
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the listing of injuries. In some embodiments, a user may select an injury from the listing 
and the injury may be considered in the insurance claim. In some embodiments, injury 
3513 may be listed. Further menus (e.g., listings of treatments for injuries) may also be 
displayed. In some embodiments, each of the body parts and injuries relative to the body 
5 parts may be displayed at the same time. In some embodiments, each level of the menu 
may only become visible as respective parts of the superceding menu are selected (e.g., 
the injuries for a body part may be displayed after the body part is selected). In some 
embodiments, the body parts and/or subparts may be nodes such that when a node is 
selected, further information (e.g., injuries) are listed relative to the node. In some 
1 0 embodiments, a scroll bar 3 5 1 5 and/or close mechanism. 3517 may be included with the 
menu. In various embodiments, the menu may be a popup menu 3507. In some 
embodiments, separate popup menus may be used for body parts and injuries. In some 
embodiments, body parts and injuries may be listed on the same popup menu 3507. In 
some embodiments, injuries may be listed under respective body parts on the popup 
15 menu. For example, after a body part has been selected, respective injuries may be 
displayed beneath the body part on the menu. In some embodiments, the popup menus 
may disappear after an injury is selected, after a user clicks off of the popup menu, or 
after a close mechanism 3517 on the popup menu is selected. In some embodiments, 
body parts and respective injuries may be displayed on a different part of the screen. For 
20 example, a fixed screen box (not shown) may be used to display body parts and injuries 
respective to a body part highlighted. In addition to body parts and injuries, in some 
embodiments, additional information and selections may be displayed. For example, 
respective treatments may be displayed under each injury. In some embodiments, when a 
user selects an injury from the menu, possible treatments for the injury may be displayed 
25 relative to the injury selected. The user may then select from the displayed treatments. 

FIG. 36 illustrates a screen shot of an embodiment for inputting and displaying 
information relative to human skin. In some embodiments, a skin representation 3607 
may be displayed when skin is selected from a listing of available representations. In an 
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embodiment, a chest 3601 may be selected and highlighted. The structure name box may 
display “Chest” 3605 indicating the name of the selected region. In some embodiments, 
injuries associated with the skin representation 3607 may include amputation, 
concussion, crush, extensive soft-tissue, de-gloving, contusion, soft-tissue, whiplash, 

5 laceration, penetration, and superficial. Other injuries may also be included (e.g., a 
closed head injury). 

FIG. 37 illustrates a screen shot of an embodiment for entering information 
relative to an abdomen region 3701. In some embodiments, a menu 3707 (e.g., a popup 
10 menu) may be displayed with body parts and subparts (e.g., diaphragm 3709). Injuries 
(e.g., contusion 3711 and laceration 3713) may be listed relative to the body parts in the 
menu to allow a user to select the appropriate injury. Other information may also be 
listed (e.g., types of treatments may be listed under each injury). 

15 FIG. 38 illustrates a screen shot of an embodiment for inputting information 

relative to a muscular representation 3802. “Muscular” 3803 may be selected from a 
listing of human body representations available and a muscular representation 3802 may 
be displayed. In some embodiments, because no information was entered relative to the 
skin representation, a check may not be placed next to the skin representation in the 
20 listing. This may assist an adjuster in remembering to go back to the skin representation 
to further input information. In some embodiments, when the chest region 3801 is 
selected, relative body parts and subparts (e.g., back, intercostals joint, left stemo 
clavicular and right stemo clavicular) may be listed in a menu displayed relative to the 
chest region 3801 . A user may select a body part, such as the left stemo clavicular 3807, 
25 and relative injuries may be displayed. For example, sprain 3809 may be selected from a 
drop down list for the left stemo clavicular 3807. 
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FIG. 39 illustrates a flowchart of an embodiment for receiving input selection 
information for a selected body part. For example, a graphical user interface may be used 
to receive information relative to a human body representation. 

5 At 3901, a graphical display in an insurance claim processing system may display 

a human body representation. In some embodiments, multiple representations including 
skeletal, muscular, and skin representations may be available. In some embodiments, a 
user may select a representation to be displayed by selecting a representation from a list 
of available representations. 

10 

At 3903, a body part on at least one human body representation may be selected. 
For example, a right shoulder may be selected. In some embodiments, the selected body 
part may be visibly distinguished from the other body parts in the representation (e.g., by 
being highlighted). 

15 

At 3905, input selection information related to the selected body part may be 
displayed. For example, a listing of possible injuries for the selected body part may be 
listed in a menu placed relative to the body part. In some embodiments, information 
relative to the body part may be displayed in a separate graphical box on a display. Other 
20 placements of information may also be used. 

At 3907, an input selection may be received via displayed input selection 
information. For example, a user may select an injury from a menu displayed relative to 
the selected body part. In some embodiments, a user may type the information related to 
25 an injury. 

FIG. 40 illustrates a flowchart of an embodiment for highlighting a selected body 
part and receiving related input. In some embodiments, a graphical user interface may be 
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used to receive information relative to a highlighted body part in a displayed human body 
representation. 

At 4001, a graphical display may be provided in an insurance claim processing 
5 system to display a human body representation. In some embodiments, an input field 
may also be displayed. For example, the input field may be a graphical box for typing in 
input related to the human body representation. In some embodiments, input may be 
entered through a menu of input selections. For example, a menu may appear for a body 
part when a mouse cursor moves over the body part. 

10 

At 4003, a listing of subparts associated with a body part may be displayed. For 
example, a menu of related subparts may be displayed for a body part when a mouse 
cursor is moved over the body part. In some embodiments, a user may click on the body 
part for the menu of related subparts to be displayed. In some embodiments, a more 
15 detailed view of the body part selected may be displayed when the user selects the body 
part. 

At 4005, a listing of injuries for the subparts may be displayed. In some 
embodiments, a listing of injuries for a subpart may be displayed under the corresponding 
20 subpart when a subpart is selected in a menu of subparts. In some embodiments, the 
injuries may be displayed automatically under the subparts in the menu. In some 
embodiments, a separate menu of injuries may be displayed for the subparts. 

At 4007, input may be received. In some embodiments, the input received may 
25 relate to a body part (e.g., the received input may correspond to an injury to a body part). 
In some embodiments, the input may be typed into an input field (e.g., a graphical box). 

In some embodiments, an input selection may be selected from a menu. For example, the 
input may be an injury selection from a listing of injuries. 
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At 4009, a body part may be highlighted on the human body representation 
corresponding to the received input. For example, if an injury is input for a right 
shoulder, the right shoulder may be highlighted. In some embodiments, body parts for 
which input has been received may be highlighted a different color than body parts for 
5 which input has not been received (e.g., body parts that are selected but have not yet had 
input entered). 

In some embodiments, extensible markup language (XML) documents may be 
used to create a graphic injury display (GID) as shown in FIGs. 32-38. For example text 
10 for view selectors (e.g., representation names in a listing of available human body 

representations) may be retrieved using information from an XML document. A display 
order attribute may be included in the XML document for each view element (e.g., parts 
of the display) to determine the order of placement of the view selectors on the GED. In 
some embodiments, each view may have an identifier by which it may be referenced. 

15 For example, in some embodiments, selected body parts (“hotspots”) may have a unique 
identifier to indicate they should be highlighted in the GID. 

Various embodiments further include receiving or storing instructions and/or data 
implemented in accordance with the description herein upon a carrier medium. Suitable 
20 carrier media include memory media or storage media such as magnetic or optical media, 
e.g., disk or CD-ROM, as well as transmission media or signals such as electrical, 
electromagnetic, or digital signals, conveyed via a communication medium such as 
networks and/or a wireless link. 

25 In this patent, certain U.S. patents, U.S. patent applications, and other materials 

(e.g., articles) have been incorporated by reference. The text of such U.S. patents, U.S. 
patent applications, and other materials is, however, only incorporated by reference to the 
extent that no conflict exists between such text and the other statements and drawings set 
forth herein. In the event of such conflict, then any such conflicting text in such 
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incorporated by reference U.S. patents, U.S. patent applications, and other materials is 
specifically not incorporated by reference in this patent. 

Although the system and method of the present invention have been described in 
connection with several embodiments, the invention is not intended to be limited to the 
specific forms set forth herein, but on the contrary, it is intended to cover such 
alternatives, modifications, and equivalents as can be reasonably included within the 
spirit and scope of the invention as defined by the appended claims. 
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